SunOS 4.x had a library known as the LWP library. There is no relationship between Solaris 2
LWPs and SunOS 4.x LWPs.
LWPs are scheduled onto the available CPU resources according to their scheduling class and
priority, as illustrated in Figure 3-6 . Because scheduling is done on a per-LWP basis, each LWP
collects its own kernel statistics--user time, system time, page faults, etc. This also implies that a
process with two LWPs will generally get twice as much CPU time as a process with only one
LWP. (This is a wild generalization, but you get the idea--the kernel is scheduling LWPs, not
Figure 3-6. Operation of a System Call
An LWP also has some capabilities that are not exported directly to threads, such as kernel
scheduling classes. A programmer can take advantage of these capabilities while retaining use of
all the thread interfaces and capabilities by specifying that the thread is to remain permanently
bound to an LWP (known as system contention scope scheduling and discussed further in
LWPs are an implementation technique for providing kernel-level concurrency and parallelism to
support the threads interface. There is never a reason for you to use the LWP interface directly.
Indeed, you should specifically avoid it. It gains you nothing but costs you your portability.
An interesting contrast to LWPs are the techniques that DEC takes. Digital UNIX has two kinds of
"LWPs," one that is an execution engine (the thing that runs on the CPU) and the other is an I/O
wait engine (which contains just enough state to move its thread back onto an execution engine).
This is nice because it minimizes the impact on the kernel of expensive programs which would
otherwise demand numerous LWPs.
In Linux, a low-level call to clone() creates a new kernel thread in the same fashion as fork()
creates a process. It also allows kernel threads of varying functionality. They can share the address
space but not file descriptors, they can share both of those but not signal handlers, etc. The one
noticeable distinction is that these kernel threads will never share a process ID in the way that
Search WWH :