Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Section - [2.2.2] Characterising implementations of multithreading

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Restaurant inspections ]


Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2.2.1] Distinguishing features
Next Document: [2.2.3] The history of threads
See reader questions & answers on this topic! - Help others by sharing your knowledge
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.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2.2.1] Distinguishing features
Next Document: [2.2.3] The history of threads

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu





Last Update March 27 2014 @ 02:11 PM