- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: oracle 7.3.x and posix threads
Operating System - HP-UX
1753899
Members
7698
Online
108809
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-01-2001 08:04 AM
02-01-2001 08:04 AM
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?
Or, more simply, is it possible to run a POSIX Threads application with a CMA-using shared library?
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-01-2001 08:13 AM
02-01-2001 08:13 AM
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.
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.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP