Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!BU-CS.BU.EDU!bzs
From: bzs@BU-CS.BU.EDU (Barry Shein)
Newsgroups: comp.society.futures
Subject: Future at Berzerkeley
Message-ID: <8903272304.AA15935@bu-cs.BU.EDU>
Date: 27 Mar 89 23:04:05 GMT
References: <13451@steinmetz.ge.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42


From: steinmetz!davidsen@uunet.uu.net  (Wm. E. Davidsen Jr)
>In article <28955@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>
>| In fact, I believe that latter example should be enough to answer the
>| question. How exactly are you going to exploit the parallel hardware
>| you're going to be screaming for soon (:-) with SysV or OSFix?
>
>  I'm not sure just what you have in mind... SysV does multiple
>processors now (UniCOS, etc) and V.4 is going to have Sun lightweight
>processes (it hasn't been pulled, has it?).

Yes, several vendors have enhanced their Unix systems to support
parallelism, all differently...that's the problem (well, challenge, to
figure out one model that is satisfactory to everyone, or at least a
limited, standardized choice of models [I am hedging because, eg, SIMD
vs. MIMD hardware probably requires different models.])

Mere lightweight processes is not sufficient (and may not even be
necessary!*) to provide a parallel programming model, there's also
scheduling and coordination among processors in the same task.

In fact, it's worse than most people think (!?), it may require
changes to programming languages (eg. if you want to lock a critical
section you can't afford the overhead of jumping to a subroutine to do
that, it leaves open a window which, with true multiprocessors, is
easily smashed through, inline expansion is probably sufficient to
solve that but hey, show me a C manual that defines a standard for
inlining!)

* For example, suppose I keep the current fork() semantics (with
shared memory) but allocate all the forks (or more) I will need at the
beginning of the task and immediately suspend them all (using job
control) and, when I need N processes I just continue the forks I need
now...suddenly fork creation overhead becomes irrelevant, no? Except
for the most trivial case where I probably won't gain much with
parallelism anyhow. Question everything!

	Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.