From: Recurrent discussions

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.

Some issues which characterise 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?

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.