Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!jgmorris
From: jgmorris@CS.CMU.EDU (Greg Morrisett)
Newsgroups: comp.os.mach
Subject: Re: Threads, Definition of
Message-ID: <JGMORRIS.91Feb14131002@VACHE.VENARI.CS.CMU.EDU>
Date: 14 Feb 91 18:10:02 GMT
References: <4964@umbc3.UMBC.EDU> <DMASON.91Feb6203244@watmsg.msg.uwaterloo.ca>
	<1476@pdxgate.UUCP> <21892@oolong.la.locus.com>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon University
Lines: 22
In-Reply-To: mjl@lccma.bos.locus.com's message of 11 Feb 91 17:58:01 GMT

Michael Leibnsperge points out that there are 2 advantages to letting
an OS know about your threads instead of doing it all in the runtime:

  a) the OS can maintain a single set of page tables for all threads,
  reducing context switch overhead when switching between two threads
  of the same task, and b) on an MP system the seperate threads can
  execute concurrently.

If you're handling context switching in the runtime, then the OS still
has only one set of page tables for your threads.  This does advantage hold
over heavy-weight processes that share memory.

There is an additional advantage to letting your OS know about your
threads:  If one thread blocks for I/O, your whole task doesn't have
to be preempted.  Some threads packages that are entirely in the
runtime get around explicit I/O preemption by doing a non-blocking call 
(e.g. select) before doing the blocking call.  But this sort of trick
isn't possible on a page fault.  Note that this advantage applies
to uni-processors as well as MPs.

-Greg Morrisett
 jgmorris@cs.cmu.edu