Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!sei!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Rick.Rashid@cs.cmu.edu
Newsgroups: comp.os.mach
Subject: Re: Threads, Definition of
Message-ID: <Ebkdkom00jdX8PA79k@cs.cmu.edu>
Date: 20 Feb 91 15:56:36 GMT
References: <1476@pdxgate.UUCP> <21892@oolong.la.locus.com> <JGMORRIS.91Feb14131059@VACHE.VENARI.CS.CMU.EDU>,
	<1991Feb20.011728.15702@cs.ubc.ca>
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 19
In-Reply-To: <1991Feb20.011728.15702@cs.ubc.ca>

A read system call blocks only the thread that makes it.

Current versions of CThreads allow a many to one
mapping of cthreads (which are the constructs Mach
user programs use) and kernel threads (which is the
kernel's notion of a computational state).  For example:
the Mach 3.0 Unix Server has potentially hundreds of
cthreads allocated to manage incoming "Unix" requests
and device messages but only around a dozen actual
kernel supplied threads are used (this number can be
varied depending on the maximum degree of parallelism
desired).  The advantage of this implementation is that
cthreads are often used to encapsulate state rather than
provide for parallelism.  Conditions and mutexs can often
be implemented using a coroutine style transfer of control
between them rather than a full reschedule.   The advantages
of kernel supplied threads (e.g., parallelism, concurrent I/O)
are available along with the advantages of procedure-call
cost thread control transfers for many operations.