cancel
Showing results for 
Search instead for 
Did you mean: 

oracle 7.3.x and posix threads

Martin John Bartlett
Occasional Visitor

oracle 7.3.x and posix threads

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?

Or, more simply, is it possible to run a POSIX Threads application with a CMA-using shared library?
1 REPLY
Alex Glennie
Honored Contributor

Re: oracle 7.3.x and posix threads

Found the following .... looks like the answers No :(

Differences
-----------
DCE (user-space only--CMA) threads are implemented entirely in user-space.
The kernel has no concept of threads. As a result, DCE threads cannot have
real parallelism to take advantage of multiple processors. The DCE package
uses the Mx1 (Many to One) threads model.

POSIX (kernel) threads use the 1x1 (One to One) thread model. In this model,
each user thread which the application creates is represented by a
corresponding kernel thread. The kernel is fully threaded and supports
threaded applications. This allows an application to fully utilize
multiprocessor hardware.

API and Libraries
-----------------
The DCE threads package adheres to Draft 4 of the POSIX threads standard.
Applications need to compile with -D_REENTRANT -D_PTHREADS_DRAFT4 and
link with -lcma.

The POSIX (kernel) threads adheres to the final version of the POSIX threads
standard (P1003.1c) and a future version of the X/Open specification.
Applications need to compile with either -D_REENTRANT or with the define
_POSIX_C_SOURCE set to 199506 or larger (#define _POSIX_C_SOURCE 199506).
Applications should link with -lpthread (or -lpthread_tr -lcl when using
the tracing version of the threads library during application development).

Compatibility
-------------
Applications cannot use DCE and kernel threads simultaneously. An application
can use either DCE or kernel threads, but not both at the same time.
This is because some interfaces in both libraries share the same name.

There is no source or binary compatibility between DCE threads and POSIX
(kernel) threads. The API is completely different between the draft version
of the standard which DCE complies with and the final POSIX standard.

Most of these differences are relatively minor. POSIX threads have a new error
return style (0 on success, error number on failure) while DCE threads have
the traditional error mechanism (0 on success, -1 on failure with errno set).
Many other differences are trivial porting changes where a parameter type
has changed, the function name is different, or an additional parameter
is required, but the semantics of the interface is different.

Signals are an area where there are significant differences between DCE
and POSIX threads. DCE supports a per-process signal mask and per-thread
signal handlers. POSIX threads have a per-thread signal mask and per-process
signal handlers.

Many *_unlocked() and *_r() functions which were available to DCE threads
are not available for POSIX threads. With POSIX threads, the non _r
counterpart of the function has been made thread-safe. The _r version is
not needed and is obsolete. DCE applications which still need to use these
obsolete interfaces should link with -ld4r.