per process and the association of user threads with LWPs is decided by the

programmer, thus both parallelism and concurrency within a process are under
the programmer s control. An n-way parallelism would be possible within a process
if the programmer created n LWPs for a process, 1 = n = p, where p is the
number of CPUs.However, the degree of parallelismwould reduce if a user thread
made a blocking system call during its operation, because the call would block
the LWP in which it is mapped. Solaris provides scheduler activations, described
later in this section, to overcome this problem.
A complex arrangement of control blocks is used to control switching
between kernel threads. The kernel thread control block contains the kernel regi
sters
of the CPU, stack pointer, priority, scheduling information, and a pointer to
the next KTCB in a scheduling list. In addition, it contains a pointer to the LW
P
control block. The LWP control block contains saved values of user registers of
the CPU, signal handling information, and a pointer to the PCB of the owner
process.
Signal Handling Signals generated by operation of a thread, such as an arithmeti
c
condition or a memory protection violation, are delivered to the thread
itself. Signals generated by external sources, such as a timer, have to be direc
ted
to a thread that has enabled its handling. TheMN model provided each process
with an LWPthat was dedicated to signal handling.When a signal was generated,
the kernel would keep it pending and notify this LWP, which would wait until
it found that some thread that had enabled handling of that specific signal was
running on one of the other LWPs of the process, and would ask the kernel to
direct the pending signal to that LWP.
States of Processes and Kernel Threads The kernel is aware only of states of
processes and kernel threads; it is oblivious to existence of user threads.Aproc
ess
can be in one of the following states:
SIDL A transient state during creation
SRUN Runnable process
SONPROC Running on a processor
SSLEEP Sleeping
SSTOP Stopped
SZOMB Terminated process
The SRUN and SSLEEP states correspond to the ready and blocked states
of Section 5.2.1. A kernel thread has states TS_RUN, TS_ONPROC, TS_SLEEP,
TS_STOPPED, and TS_ZOMB that are analogous to the corresponding process
states. A kernel thread that is free is in the TS_FREE state.
Scheduler Activations A scheduler activation is like a kernel thread. The kernel
uses scheduler activations to perform two auxiliary functions: (1) When some
LWP of the process becomes blocked, the kernel uses a scheduler activation to
create a new LWP so that other runnable threads of the process could operate.
(2)When an event related to the operation of the thread library occurs, the kern
el
uses a scheduler activation to notify the thread library.
Chapter 5 Processes and Threads 157
Consider a many-to-one mapping between many user threads and an LWP,
and a user thread that is currently mapped into the LWP. A kernel thread is
associated with the LWP, so the user thread operates when the kernel thread is
scheduled. If the user thread makes a blocking system call, the kernel thread
would block. Effectively, the LWP with which it is associated would block. If
some of the other threads that are mapped into the same LWP are runnable, we
have a situation where a runnable user thread cannot be scheduled because the
LWP has become blocked.
In such situations, the kernel creates a scheduler activation when the user
thread is about to block, provides the activation to the thread library, and mak

es
an upcall to it. The upcall is implemented as a signal sent to the thread librar
y.
The thread library now executes its signal handler, using the activation provide
d
by the kernel. The signal handler saves the state of the user thread that is abo
ut
to block, releases the LWP that was used by it, and hands it over to the kernel
for reuse. It now schedules a new user thread on the new activation provided by
the kernel. In effect, the user thread that was about to block is removed from a
n
LWP and a new user thread is scheduled in a new LWP of the process.When the
event for which the user thread had blocked occurs, the kernel makes another
upcall to the thread library with a scheduler activation so that it can preempt
the user thread currently mapped into the LWP, return the LWP to the kernel,
and schedule the newly activated thread on the new activation provided by the
kernel.