Linker Thread-Safe Features
The dynamic loader (dld) and its application interface library (libdl) are thread-safe.
Also, the linker toolset provides thread local storage support in:
•ld - the link editor
•crt0.o - the program startup file
Thread local storage (also called thread-specific data) is data specific to a thread. Each thread has its own copy of the data item.
NOTE: Use of the __thread keyword in a shared library prevents that shared library from being dynamically loaded, that is, loaded by an explicit call to shl_load().
For More Information:
•See your HP compiler documentation to learn how to create thread local storage data items with the _thread compiler directive.
•See Programming with Threads on HP-UX for information on threads.
Shared library loading and unloading in multi-threaded applications
The dynamic loader serializes all calls to dlopen, dlclose, shl_load, and shl_unload using
apthread mutex lock. A thread executing dlopen holds this lock, and another thread that wants to execute dlclose (for example), even on a different shared library, must wait for the dlopen in the first thread to release the lock after it is done.
Developers, who use these routines in multi-threaded applications (or shared libraries) and also use mutex locks for synchronizing threads should take note of this behavior to avoid deadlock situations. One example of such a situation is when a shared library initializer creates a new thread that calls dlopen - this would invariably lead to a deadlock in a multi-threaded application. A less trivial example could be as follows. Suppose thread A of an application calls dlopen to load a shared library, libA. Now this shared library has an initializer initA that wants to obtain a mutex lock M. But M is currently held by thread B of the application. Further, thread B wants to load another library, libB and then release the mutex lock M. Now thread B would call either dlopen or shl_load, either of which waits for the dld mutex lock to be released by the dlopen called by thread A. In turn, thread A waits for mutex lock M to be released before it can finish dlopen and release the dld mutex lock. This results in a deadlock.
