<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: oracle 7.3.x and posix threads in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-7-3-x-and-posix-threads/m-p/2488943#M800684</link>
    <description>Found the following .... looks like the answers No :(&lt;BR /&gt;&lt;BR /&gt;Differences&lt;BR /&gt;-----------&lt;BR /&gt;DCE (user-space only--CMA) threads are implemented entirely in user-space.&lt;BR /&gt;The kernel has no concept of threads. As a result, DCE threads cannot have&lt;BR /&gt;real parallelism to take advantage of multiple processors. The DCE package&lt;BR /&gt;uses the Mx1 (Many to One) threads model.&lt;BR /&gt;&lt;BR /&gt;POSIX (kernel) threads use the 1x1 (One to One) thread model. In this model,&lt;BR /&gt;each user thread which the application creates is represented by a&lt;BR /&gt;corresponding kernel thread. The kernel is fully threaded and supports&lt;BR /&gt;threaded applications. This allows an application to fully utilize&lt;BR /&gt;multiprocessor hardware.&lt;BR /&gt;&lt;BR /&gt;API and Libraries&lt;BR /&gt;-----------------&lt;BR /&gt;The DCE threads package adheres to Draft 4 of the POSIX threads standard.&lt;BR /&gt;Applications need to compile with -D_REENTRANT -D_PTHREADS_DRAFT4 and&lt;BR /&gt;link with -lcma.&lt;BR /&gt;&lt;BR /&gt;The POSIX (kernel) threads adheres to the final version of the POSIX threads&lt;BR /&gt;standard (P1003.1c) and a future version of the X/Open specification.&lt;BR /&gt;Applications need to compile with either -D_REENTRANT or with the define&lt;BR /&gt;_POSIX_C_SOURCE set to 199506 or larger (#define _POSIX_C_SOURCE 199506).&lt;BR /&gt;Applications should link with -lpthread (or -lpthread_tr -lcl when using&lt;BR /&gt;the tracing version of the threads library during application development).&lt;BR /&gt;&lt;BR /&gt;Compatibility&lt;BR /&gt;-------------&lt;BR /&gt;Applications cannot use DCE and kernel threads simultaneously. An application&lt;BR /&gt;can use either DCE or kernel threads, but not both at the same time.&lt;BR /&gt;This is because some interfaces in both libraries share the same name.&lt;BR /&gt;&lt;BR /&gt;There is no source or binary compatibility between DCE threads and POSIX&lt;BR /&gt;(kernel) threads. The API is completely different between the draft version&lt;BR /&gt;of the standard which DCE complies with and the final POSIX standard.&lt;BR /&gt;&lt;BR /&gt;Most of these differences are relatively minor. POSIX threads have a new error&lt;BR /&gt;return style (0 on success, error number on failure) while DCE threads have&lt;BR /&gt;the traditional error mechanism (0 on success, -1 on failure with errno set).&lt;BR /&gt;Many other differences are trivial porting changes where a parameter type&lt;BR /&gt;has changed, the function name is different, or an additional parameter&lt;BR /&gt;is required, but the semantics of the interface is different.&lt;BR /&gt;&lt;BR /&gt;Signals are an area where there are significant differences between DCE&lt;BR /&gt;and POSIX threads. DCE supports a per-process signal mask and per-thread&lt;BR /&gt;signal handlers. POSIX threads have a per-thread signal mask and per-process&lt;BR /&gt;signal handlers.&lt;BR /&gt;&lt;BR /&gt;Many *_unlocked() and *_r() functions which were available to DCE threads&lt;BR /&gt;are not available for POSIX threads. With POSIX threads, the non _r&lt;BR /&gt;counterpart of the function has been made thread-safe. The _r version is&lt;BR /&gt;not needed and is obsolete. DCE applications which still need to use these&lt;BR /&gt;obsolete interfaces should link with  -ld4r.&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Thu, 01 Feb 2001 16:13:56 GMT</pubDate>
    <dc:creator>Alex Glennie</dc:creator>
    <dc:date>2001-02-01T16:13:56Z</dc:date>
    <item>
      <title>oracle 7.3.x and posix threads</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-7-3-x-and-posix-threads/m-p/2488942#M800683</link>
      <description>We have an application that lightly uses posix threads and runs with Oracle 8.0.x 8.1.x DB/2 - and NOT Oracle 7.3.x for well known reasons concerning POSIX Threads and CMA Threads. So, my question is, is there ANY way we can keep our generic, highly complex application code as is (supporting all the recent Oracles and DB/2) AND support Oracle 7.3.x at the same time?&lt;BR /&gt;&lt;BR /&gt;Or, more simply, is it possible to run a POSIX Threads application with a CMA-using shared library?</description>
      <pubDate>Thu, 01 Feb 2001 16:04:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-7-3-x-and-posix-threads/m-p/2488942#M800683</guid>
      <dc:creator>Martin John Bartlett</dc:creator>
      <dc:date>2001-02-01T16:04:19Z</dc:date>
    </item>
    <item>
      <title>Re: oracle 7.3.x and posix threads</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-7-3-x-and-posix-threads/m-p/2488943#M800684</link>
      <description>Found the following .... looks like the answers No :(&lt;BR /&gt;&lt;BR /&gt;Differences&lt;BR /&gt;-----------&lt;BR /&gt;DCE (user-space only--CMA) threads are implemented entirely in user-space.&lt;BR /&gt;The kernel has no concept of threads. As a result, DCE threads cannot have&lt;BR /&gt;real parallelism to take advantage of multiple processors. The DCE package&lt;BR /&gt;uses the Mx1 (Many to One) threads model.&lt;BR /&gt;&lt;BR /&gt;POSIX (kernel) threads use the 1x1 (One to One) thread model. In this model,&lt;BR /&gt;each user thread which the application creates is represented by a&lt;BR /&gt;corresponding kernel thread. The kernel is fully threaded and supports&lt;BR /&gt;threaded applications. This allows an application to fully utilize&lt;BR /&gt;multiprocessor hardware.&lt;BR /&gt;&lt;BR /&gt;API and Libraries&lt;BR /&gt;-----------------&lt;BR /&gt;The DCE threads package adheres to Draft 4 of the POSIX threads standard.&lt;BR /&gt;Applications need to compile with -D_REENTRANT -D_PTHREADS_DRAFT4 and&lt;BR /&gt;link with -lcma.&lt;BR /&gt;&lt;BR /&gt;The POSIX (kernel) threads adheres to the final version of the POSIX threads&lt;BR /&gt;standard (P1003.1c) and a future version of the X/Open specification.&lt;BR /&gt;Applications need to compile with either -D_REENTRANT or with the define&lt;BR /&gt;_POSIX_C_SOURCE set to 199506 or larger (#define _POSIX_C_SOURCE 199506).&lt;BR /&gt;Applications should link with -lpthread (or -lpthread_tr -lcl when using&lt;BR /&gt;the tracing version of the threads library during application development).&lt;BR /&gt;&lt;BR /&gt;Compatibility&lt;BR /&gt;-------------&lt;BR /&gt;Applications cannot use DCE and kernel threads simultaneously. An application&lt;BR /&gt;can use either DCE or kernel threads, but not both at the same time.&lt;BR /&gt;This is because some interfaces in both libraries share the same name.&lt;BR /&gt;&lt;BR /&gt;There is no source or binary compatibility between DCE threads and POSIX&lt;BR /&gt;(kernel) threads. The API is completely different between the draft version&lt;BR /&gt;of the standard which DCE complies with and the final POSIX standard.&lt;BR /&gt;&lt;BR /&gt;Most of these differences are relatively minor. POSIX threads have a new error&lt;BR /&gt;return style (0 on success, error number on failure) while DCE threads have&lt;BR /&gt;the traditional error mechanism (0 on success, -1 on failure with errno set).&lt;BR /&gt;Many other differences are trivial porting changes where a parameter type&lt;BR /&gt;has changed, the function name is different, or an additional parameter&lt;BR /&gt;is required, but the semantics of the interface is different.&lt;BR /&gt;&lt;BR /&gt;Signals are an area where there are significant differences between DCE&lt;BR /&gt;and POSIX threads. DCE supports a per-process signal mask and per-thread&lt;BR /&gt;signal handlers. POSIX threads have a per-thread signal mask and per-process&lt;BR /&gt;signal handlers.&lt;BR /&gt;&lt;BR /&gt;Many *_unlocked() and *_r() functions which were available to DCE threads&lt;BR /&gt;are not available for POSIX threads. With POSIX threads, the non _r&lt;BR /&gt;counterpart of the function has been made thread-safe. The _r version is&lt;BR /&gt;not needed and is obsolete. DCE applications which still need to use these&lt;BR /&gt;obsolete interfaces should link with  -ld4r.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 01 Feb 2001 16:13:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-7-3-x-and-posix-threads/m-p/2488943#M800684</guid>
      <dc:creator>Alex Glennie</dc:creator>
      <dc:date>2001-02-01T16:13:56Z</dc:date>
    </item>
  </channel>
</rss>

