Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!cs.utexas.edu!yale!quasi-eli!cs.yale.edu!briscoe-duke
From: briscoe-duke@cs.yale.edu (Duke Briscoe)
Newsgroups: comp.os.mach
Subject: Re: Threads, Definition of
Message-ID: <28949@cs.yale.edu>
Date: 20 Feb 91 21:12:01 GMT
References: <1476@pdxgate.UUCP> <21892@oolong.la.locus.com> <1991Feb20.011728.15702@cs.ubc.ca> <12032@pt.cs.cmu.edu>
Sender: news@cs.yale.edu
Reply-To: briscoe-duke@cs.yale.edu (Duke Briscoe)
Organization: Yale University, Dept. of Computer Science, New Haven, CT
Lines: 15
Nntp-Posting-Host: pullback.systemsz.cs.yale.edu
Originator: briscoe@pullback.CS.Yale.Edu


In article <12032@pt.cs.cmu.edu>, af@spice.cs.cmu.edu (Alessandro Forin) writes:
|> 
|> How comes noone thinks that maybe, just maybe, parallelism is
|> most appropriately discussed with a multiprocessor machine in mind ?
|> Fake parallelism does not speedup your programs, you know...

Actually, I thought threads packages can speed up your programs on a
uniprocessor since processor utilization can be improved by masking
the latency of things such as page faults and I/O.  If you can write a
program with multiple threads, even on a single processor the cpu
doesn't have to be idle if one particular thread blocks.  This assumes
that the scheduler knows about threads, as I think Mach does.

Duke