Path: utzoo!mnetor!uunet!husc6!psuvax1!vu-vlsi!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.arch
Subject: Re: Single tasking the wave of the future?
Message-ID: <2989@cbmvax.UUCP>
Date: 21 Dec 87 22:11:53 GMT
References: <25@amelia.nas.nasa.gov>
Organization: Commodore Technology, West Chester, PA
Lines: 41

in article <25@amelia.nas.nasa.gov>, fouts@orville.nas.nasa.gov (Marty Fouts) says:
> In article <2341@encore.UUCP> fay@encore.UUCP (Peter Fay) writes:
>>In regard to general-purpose multiprocessors:
>>Every fork() (or thread_create() in Mach) in every program can get
>>scheduled on a different cpu (that includes every shell per user,
>>daemon, background task, ... Also, don't forget all those kernel
>>processes (or tasks, threads) running on different cpus (pagers,
>>signal handlers, ...). How difficult is it when the O.S.  does it
>>transparently? 

> Mr. Fay is using transparently in a way with which I am unfamilar.  It
> is true that Mach provides primitives which allow the programmer to
> introduce multitasking into the program; but these are in no sense
> transparent.  Task creation and deletion, synchronization, and task
> scheduling all require explict code in the program which is to take
> advantage of the tasking.  Even the ancient Unix fork() has to be
> explicitly coded for.

I believe he's referring to the processor the code is executing on, not the
specific request for threading, as being transparent.  Right now if you
fork() or thread_create(), you start an asynchronous task of some kind that's
time shared on the same physical CPU.  In the proposed senario, the OS will
break up the tasks as evenly as possible amoung the existing CPUs in the
system.  This distribution is completely transparent to the programmer; it
doesn't look any different than if it were running on a single machine, other
than the large increase in execution speed you may get.

This of course bypasses any of the arguments you get into when you introduce
more sophisticated ways of using the multiple processors, like vectorizing
or parallelizing compilers.  Tasks are already atomic units and trivial to
break up between CPUs, and the synchronization mechanisms are already put in
place by the programmer.  Of course, if you were writing code specifically
for a machine like this with 5 or 10 CPUs, you'd consider multiple tasks as
a speed enhancing device in many cases, where on the single CPU machine
they'd likely slow down your program.  A good argument for lightweight tasks
like what you get in Mach.

-- 
Dave Haynie     Commodore-Amiga    Usenet: {ihnp4|uunet|rutgers}!cbmvax!daveh
   "The B2000 Guy"              PLINK : D-DAVE H             BIX   : hazy
		"I can't relax, 'cause I'm a Boinger!"