- The following was excerpted from the
os-faq:
User/Kernel Implementations
An important distinction may be made between user-level threads and
kernel-supported threads. A user-level thread maintains all its state
in user space. A consequence of this is that no kernel resources need
to be allocated per thread, and switching between threads can be done
without changing address space. A disadvantage is that user level
threads cannot execute while the kernel is busy, for instance, with
paging or I/O. This would require some knowledge and participation on
the part of the kernel.
It is possible to combine both methods, as is done in SunOS 5.x (aka
Solaris 2.x). Here, one or more light weight processes (LWPs)
multitask one or more user-level threads, which in turn are
implemented using user-space libraries.
Characterizing Implementations
- Some issues which characterize thread implementations, and which
determine the uses to which a threads package may be put, include:
- How much by way of kernel resources does a thread require? This
will typically limit the number of threads that can be started by a
process.
- Under what circumstances will the entire process hang? For
instance, if some thread gets a page fault, may another thread in
that process be dispatched?
- Does switching threads require a full system call (as on the SPARC),
or may context switches between threads be performed entirely at
user level?
- How are signals handled? Can signals be masked individually per
thread? Is there a `broadcast' signal?
- How are stacks handled? Will the stacks shrink/grow dynamically on
a per thread basis?
Alternatives To Threads
Several systems today (QNX and Plan 9, for instance) take the stance
that threads `fix the symptom, but not the problem'. Rather than
using threads because the OS context switch time is too slow, a better
approach, according to the architects of these systems, is to fix the
OS. It's ironic, now that even PC-hosted desktop OSes provide
MMU-protected multitasking, the fashionable programming model has
become multiple threads running in a common address space, making
debugging difficult, and also making it more difficult to generate
reliable code. With fast context switching, existing OS services like
explicitly allocated shared memory between a team of cooperating
processes can create a `threaded' environment, without opening the
Pandora's box of problems that a fully shared memory space entails.
|
