However, creating and destroying threads as they are required is usually more expensive than managing a pool of threads that wait for independent work.
While thread creation has less overhead compared to that of process creation, it is not efficient when compared to the cost of a few instructions. Create threads for processing that lasts at least a couple of thousand machine instructions.
Figure 9–1illustrates the relationship between LWPs and the user and kernel levels.
The user-level threads library ensures that the number of LWPs available is adequate for the currently active user-level threads. The operating environment decides which LWP should run on which processor and when. It has no knowledge about user threads. The kernel schedules LWPs onto CPU resources according to their scheduling classes and priorities.
The new threads library introduced in Solaris 9 actually assigns one LWP to every thread. This is the same as the alternate libthread in Solaris 8.
The new implementation solves many problems that were inherent in the design of the old threads library, principally in the areas of signal handling and concurrency. The new threads library does not have to be told the desired degree of concurrency via thr_setconcurrency(3THR) because every thread executes on an LWP.
In future Solaris releases, the threads library might reintroduce multiplexing of unbound threads over LWPs, but with the constraints currently in effect for Solaris 9:
all runnable threads are attached to LWPs
no hidden threads are created by the library itself
a multithreaded process with only one thread has semantics identical to the semantics of a traditional single threaded process.
The library invokes LWPs as needed and assigns them to execute runnable threads. The LWP assumes the state of the thread and executes its instructions. If the thread becomes blocked on a synchronization mechanism, the threads library may save the thread state in process memory and assign another thread to the LWP to run.
Bound threads are guaranteed to execute on the same LWP from the time the thread is created to the time the thread exits.
Here are some simple guidelines for using threads.
Use threads for independent activities that must do a meaningful amount of work.
Use bound threads only when a thread needs resources that are available only through the underlying LWP, such as when the thread must be visible to the kernel, as in realtime scheduling.