Pthread Stubs in C Library

ManualsBrandsHP ManualsSoftwareHP C/aC++ for PA-RISC Software

Pthread stubs in C library - Release Notes

Problem

On HP-UX if a non-threaded application links to a thread-safe library, calls to thread safe routines from the

application fail at run time due to unresolved symbols of the form of pthread_*. To resolve these symbols it is

necessary to link the non-threaded application to a threads library (libpthread or libcma). But linking to that library

forces the application to use thread-safe features even if it creates no threads, with subsequent loss of performance.

Resolution

Due to the problems stated above, HP has decided to implement POSIX 1x thread stubs.

Providing POSIX 1c thread stubs in HP-UX C language library have two direct effects for non-threaded applications:

a) POSIX 1c thread symbols are resolved if a non-threaded application links to a thread-safe library.

b) We avoid the overhead of a real thread library especially the overhead associated with mutexes when the non-

threaded application uses thread stubs rather than the real thread library procedures.

As per the libc cumulative patches, PHCO_22923 (11.00) and PHCO_23772 (11.11), the libc shared library contains

stubs for the pthread_* functions in libpthread and libcma. The stubs allow non-threaded applications to dynamically

load thread-safe libraries successfully, so that the pthread symbols are resolved. Applications that resolves pthread/cma

calls to the stub must be built without -lpthread or -lcma on the link line.

Stubs provided in libc do not have any functionality, these are dummy functions returning zero except

pthread_getspecific() family of APIs which has full functionality implemented in the stubs.

List of pthread calls for which the stubs are provided in the C library is given below.

pthread_atfork(3T)

pthread_attr_destroy(3T)

pthread_attr_getdetachstate(3T)

pthread_attr_getguardsize(3T)

pthread_attr_getinheritsched(3T)

pthread_attr_getschedparam(3T)

pthread_attr_getschedpolicy(3T)

pthread_attr_getscope(3T)

pthread_attr_getstackaddr(3T)

pthread_attr_getstacksize(3T)

pthread_attr_setdetachstate(3T)

pthread_attr_setguardsize(3T)

pthread_attr_setinheritsched(3T)

pthread_attr_setschedparam(3T)

pthread_attr_setschedpolicy(3T)

pthread_attr_setscope(3T)

pthread_attr_setstackaddr(3T)

pthread_attr_setstacksize(3T)

pthread_cancel(3T)

pthread_cond_broadcast(3T)

pthread_cond_destroy(3T)

pthread_cond_init(3T)

pthread_cond_signal(3T)

pthread_cond_timedwait(3T)

pthread_cond_wait(3T)

Summary of content (7 pages)

PAGE 1
Pthread stubs in C library - Release Notes Problem On HP-UX if a non-threaded application links to a thread-safe library, calls to thread safe routines from the application fail at run time due to unresolved symbols of the form of pthread_* . To resolve these symbols it is necessary to link the non-threaded application to a threads library (libpthread or libcma). But linking to that library forces the application to use thread-safe features even if it creates no threads, with subsequent loss of performance.
PAGE 2
pthread_condattr_destroy(3T) pthread_condattr_getpshared(3T) pthread_condattr_init(3T) pthread_condattr_setpshared(3T) pthread_continue(3T) pthread_detach(3T) pthread_getconcurrency(3T) pthread_getschedparam(3T) pthread_join(3T) pthread_kill(3T) pthread_mutex_destroy(3T) pthread_mutex_getprioceiling(3T) pthread_mutex_init(3T) pthread_mutex_lock(3T) pthread_mutex_setprioceiling(3T) pthread_mutex_trylock(3T) pthread_mutex_unlock(3T) pthread_mutexattr_destroy(3T) pthread_mutexattr_getprioceiling(3T) pthread_mu
PAGE 3
pthread_key_create(3T) pthread_getspecific(3T) pthread_setspecific(3T) ptherad_key_delete(3T) pthread_exit(3T) Calls to the stub, pthread_self(3T) always returns 1 pthread_equal(arg1, arg2) returns (arg1 == arg2) pthread_create(3T) and pthread_attr_init(3T) returns ENOSYS. Link Order problems: An application may inadvertently pick up the stubs present in libc when it is intended to use the real pthread APIs, or cma APIs. These are link order problems.
PAGE 4
shared library binding: deferred global hash table disabled $ cc thread.c -lpthread $ a.out Success $ chatr a.out a.out: shared executable shared library dynamic path search: SHLIB_PATH disabled second embedded path disabled first Not Defined shared library list: dynamic /usr/lib/libpthread.1 dynamic /usr/lib/libc.
PAGE 5
By default, the compiler drivers (cc, aCC, f90) automatically pass –lc to the linker at the end of the link line of the executables. It is not necessary to specify -lc when building a shared library because libc will be resolved by the reference to libc in the executable build command. The libc will be resolved by -lc that is automatically passed by the compiler drivers to the linker.
PAGE 6
libc libpthread Therefore the load graph is constructed as: lib1.sl --> lib2.sl -->libc.2 --> libpthread.1 This is the desired behavior for non-threaded applications, but causes threaded applications (that use either libpthread or libcma) to fail. # lib1.sl specifies -lc; lib2.sl specifies no -lpthread on a.out -lpthread; $ cc -c +z +DA2.0W lib1.c lib2.c lib1.c: lib2.c: $ ld -b -o lib1.sl -lc lib1.o $ ld -b -o lib2.sl -lpthread lib2.o $ cc +DA2.0W thread.c -L. -l1 -l2 $ a.
PAGE 7
libc.2 => /usr/lib/pa20_64/libc.2 libpthread.1 => /lib/pa20_64/libpthread.1 libdl.1 => /usr/lib/pa20_64/libdl.1 Example 2 (archived libc): If the link line of your shared library contains -lc to explicitly link in libc, remove –lc . Otherwise, shared libraries may be referencing libc.2 while the a.out may reference some older (archived) libc version. Thus the application will actually be using two different versions of libc and possibly mixing code.