March 16, 2001, 4:54 PM —
Let's start by revisiting what we know.
We know that Solaris implements a two-layer threads model. The model defines thread abstractions at both the kernel and user layers, and user threads are created using thread library interfaces.
In the kernel, there are two entities abstracted: the kernel thread and the LWP. We think of kernel threads and LWPs as a single entity because every kernel thread that exists on behalf of a user process has a corresponding LWP, and vice versa. We know from past columns that the kernel thread/LWP combinations is what's scheduled by the kernel on an available processor.
Lastly, we know that the scheduling of an unbound user thread requires that the user thread be linked to an available LWP. This happens at the threads library level, through well-defined preemption points in the library code.
This brings us to the subject at hand, the implementation of the pool of available LWPs for unbound threads. (Remember that by definition bound threads always have an available LWP.) If there are more runnable user threads in a process than available LWPs, user threads must wait until the pool of LWPs is replenished before they can be scheduled. Conversely, more LWPs than user threads require maintenance and consume resources (a kernel stack) without serving as an execution resource of threads. Thus, the system must continually find a balance between keeping enough LWPs available for runnable user threads and keeping the pool small enough so as not to waste kernel resources.
The original solution to this problem in Solaris was built on the signals model. Basically, if all the LWPs in the process were blocked, a SIGWAITING signal was sent from the kernel to the threads library, where a SIGWAITING signal handler would create a new LWP. This system works as long as user threads are issuing system calls and entering the kernel. If a user thread is compute bound in user code, it's possible for the runnable user threads to wait indefinite periods of time for an available LWP, as the kernel has no way of knowing if a particular process has runnable user threads and needs more LWPs.
The method of detection and replenishment of LWPs for the threads library went through some changes beginning in Solaris 2.6. A new subsystem built on doors was introduced. However, the original mechanism is still in place, and, under certain conditions, SIGWAITING is still used. Let's take a closer look at the original implementation, and then look at the doors-based code.
A multithreaded program is any program that's been linked with the threads library at compile time. The program itself doesn't have to include any explicit calls to threads application programming interfaces (APIs); if the threads library is linked in, Solaris considers it to be a multithreaded program. For multithreaded programs, a couple of threads created on behalf of the threads library appear in the running process.
The following example shows a dbx(1) session in a dummy program that was linked at compile time to libpthread but doesn't make any threads API calls (in fact, it doesn't issue any system calls at all). The program, dbx list command below.
I added line numbers to the output to simplify subsequent annotations.
