Newsgroups: comp.os.mach
Path: utzoo!utgpu!watserv1!watmath!watmath!dmason
From: dmason@watmsg.uwaterloo.ca (Dave Mason)
Subject: Re: Threads, Definition of
In-Reply-To: mjl@lccma.bos.locus.com's message of 11 Feb 91 17:58:01 GMT
Message-ID: <DMASON.91Feb12120732@watmsg.uwaterloo.ca>
Sender: daemon@watmath.waterloo.edu (0000-Admin(0000))
Organization: /u/dmason/.organization
References: <4964@umbc3.UMBC.EDU> <DMASON.91Feb6203244@watmsg.msg.uwaterloo.ca>
	<1476@pdxgate.UUCP> <21892@oolong.la.locus.com>
Date: 12 Feb 91 12:07:32
Lines: 21

In article <21892@oolong.la.locus.com> mjl@lccma.bos.locus.com (Michael Leibensperger) writes:

> The advantages of having the OS know about threads (as in
> Mach) are: a) the OS can maintain a single set of page tables for all
> threads, reducing the context switch overhead when switching between two
> threads of the same task, and b) on an MP system the seperate threads
> can execute concurrently.

On the other hand, the disadvantage of existing threads system vs.
user-level lightweight processes is that some (most, in some systems)
inter-thread interactions require a system call with an overhead cost
10-1000 times greater than the actual required instructions.

This can be very bad if the LWPs only have a few dozens of
instructions to execute between such interactions.

> I await my due share of fawning adoration....  ;-)

OK: You gave the case for the pro-threads camp very well :-)

	../Dave