Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!hao!ames!amelia!orville.nas.nasa.gov!fouts
From: fouts@orville.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.arch
Subject: Re: Single tasking the wave of the future?
Message-ID: <49@amelia.nas.nasa.gov>
Date: 22 Dec 87 18:13:52 GMT
References: <25@amelia.nas.nasa.gov> <2989@cbmvax.UUCP>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@orville.nas.nasa.gov (Marty Fouts)
Lines: 22

In article <2989@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:

>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.
>

The last part of this isn't precisely true.  I have frequently found
that timing problems in multitasked codes, especially those which are
synchronization primitive bugs will not show up in single processor
execution because of "accidental" synchronization as a result of
sharing the single processor.  Even pipelines can give different
behaviour on a multiprocessor than on a uniprocessor, although the
producer/consumer synchronization usually prevents this.

There just isn't any such thing as transparent when dealing with
cooperatively multitasked codes.