It used to contain the memory map, the signal dispatch table, signal mask, user ID, group ID,
working directory, etc., along with runtime statistics, CPU state (registers, etc.), and a kernel stack
(for executing system calls). In Solaris 2, the last couple bits have been abstracted out and placed
into a new structure called a lightweight process (LWP). So a process contains all of the above,
except for the runtime statistics, CPU state, and kernel stack, which are now part of the LWP
structure. A process thus contains some number of LWPs (one for a "traditional" process, more for
a multithreaded process). Just as the threads all share the process variables and state, the LWPs do
The other operating systems that support user-level threads have different ways of dealing with
the same issue. Some of them copy the entire process structure for each thread, some of them
don't do anything. The concept of a separate, schedulable entity, such as the LWP, proves to be an
excellent pedagogical concept, and the other designs can easily be described in terms of LWPs.
LWP is, of course, a Solaris term.
The process structure shown in Figure 3-1 is in kernel space--below the solid line in the figures. It
is not directly accessible by any user code. User code can access it only via a system call. That
restriction allows the kernel to check the legality of the call and prevent user code from doing
things it shouldn't, either by intention or mistake. Because a system call is required to access the
process structure information, it is a more costly operation than a function call.
A lightweight process can be thought of as a virtual CPU that is available for executing code.
Each LWP is separately scheduled by the kernel. It can perform independent system calls and
incur independent page faults, and multiple LWPs in the same process can run in parallel on
Search WWH :