Multithreaded Programming Guide

Linking With the Alternate One-level libthread Library

The standard Solaris threads implementation is built upon a two-level threading model in which user-level threads are multiplexed over possibly fewer lightweight processes, or LWPs. An LWP is the fundamental unit of execution that is dispatched to a processor by the operating system. A mechanism is provided in the standard implementation for associating threads one-to-one with LWPs (the THR_BOUND and PTHREAD_SCOPE_SYSTEM flags) for writing applications with one-level semantics.

The Solaris 8 Operating Environment provides an alternate threads implementation of a one-level model in which user-level threads are associated one-to-one with LWPs. This implementation is simpler than the standard implementation and may be beneficial to some multithreaded applications. It provides exactly the same interfaces, both for POSIX threads and Solaris threads, as the standard implementation.

To link with the alternate implementation, use the following run-path -R option when linking the program.

For POSIX threads use:


cc -mt ... -lpthread ... -R /usr/lib/lwp        (32-bit)
cc -mt ... -lpthread ... -R /usr/lib/lwp/64     (64-bit)

For Solaris threads use:


cc -mt ... -R /usr/lib/lwp                   (32-bit)
cc -mt ... -R /usr/lib/lwp/64                (64-bit)

For multithreaded programs that have been previously linked with the standard threads library, the environment variable LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 can be set as follows to bind the program at run time to the alternate threads library:


LD_LIBRARY_PATH=/usr/lib/lwp
LD_LIBRARY_PATH=/usr/lib/lwp:/usr/lib/lwp/64

Note that if an LD_LIBRARY_PATH environment variable is in effect for a secure process, then only the trusted directories specified by this variable will be used to augment the runtime linker's search rules.

When using the alternate one-level threads implementation, the library might create more LWPs than the standard implementation using unbound threads. LWPs consume operating system memory in contrast to threads, which consume only user-level memory. Thus, a multithreaded application linked with this library that creates thousands of threads would create an equal number of LWPs and might run the system out of resources required to support the application.