Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!decwrl!argosy!jay
From: jay@argosy.UUCP (Jay O'Conor)
Newsgroups: comp.sys.mac.system
Subject: Re: PPC, IAC, and True Multitasking (tm)
Message-ID: <652@argosy.UUCP>
Date: 20 Aug 90 22:40:44 GMT
References: <1990Aug3.040513.14844@d.cs.okstate.edu> <2760@bridge2.ESD.3Com.COM> <13888@cbmvax.commodore.com>
Sender: news@argosy.UUCP
Reply-To: jay@idiot.UUCP (Jay O'Conor)
Organization: MasPar Computer Corporation, Sunnyvale, CA
Lines: 99

In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes:
>In article <2760@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman
>Goodger) writes:
>>
>>	Despite the -:)'s, I say there is no such thing as "True 
>>	MultiTasking", you either have "pre-emptive" or "cooperative"
>>	MultiTasking. Take your pick...
>
>Actually, you either have pre-emptive multitasking, or you have nothing. Taking
>it your way, my Apple II has cooperative multitasking since it allows me to
>load two specially written executables at two different locations, which then
>branch into each other when they have completed part of their task.

Hmmm.  I strongly disagree with this.  Both pre-emptive and cooperative
multitasking are valid implementations of multitasking.  Why does it
make any difference whether or not a task-switch occurs off a clock tick
interrupt?  As long as the O/S will allot time to other tasks without
the knowledge of other tasks, then multitasking is achieved.  On the
Mac, task switches take place at Get/WaitNextEvent and EventAvail.
These O/S calls are not made for the explicit purpose of relinquishing
the processor, but instead to get operator input.  Gee, I would hope
that any multitasking system would take advantage if the time spent
waiting for input to run other tasks.
>
>Of course the Mac has much more built-in support for such a cooperative effort,
>but multitasking is not a feature which can be quantitized. Either you have it,
>or you don't. An operating system has a pre-emptive scheduler, or it doesn't
>have one at all. There is no such thing as a cooperative scheduler. The term
>cooperative is used when there is an absence of a scheduler.

I only partially disagree here.  Even in a cooperative multitasking
system, priority scheduling can take place.  Just not time scheduling.
The cooperative 'scheduler' still is responsible for choosing the next
task to run.  It may implement a simple round-robin policy, or any
priority scheme the O/S designer chooses.  If this is not a scheduler,
what would you call it?

>
>> Pre_emptive Multitasking I suspect will slow down performance
>> of current Mac's to much to be acceptable.
>
>You misunderstand the concepts behind (pre-emptive) multitasking. The idea is
>to have the kernel interrupt the task in progress if another task of a higher
>priority is ready to run or if the quantum of the current one is over. If there
>is no other other task ready to run, task switching never occurrs.

I agree 100% here.  Although an argument could be made that the overhead
of the clock interrupt handler having to check for a new task to run
could be significant. In the case of the Mac, there's so many things
that already occur at interrupt time I would suspect that checking for a
new task to run wouldn't be much more.

>
>Therefore, whether each task is responsible for lanching cooperatively other
>tasks, or whether the operating system does that, has nothing to do with the
>speed at which these tasks will run. Factors which could affect the speed are
>
>1. the size of the time slice (quantum)
>2. overhead of the dispatcher
>3. the memory model (independent or common address spaces, memory protection,
>   virtual memory, etc.)
>
>If anything, a preemptive operating system will be faster, because it will
>perform task switching only when necessary. The preemptive operating system
>will also allow the user to set task priorities. Thus if the user wants task B
>to run only when task A is waiting for an event to complete, all it has to do
>is lower its priority below that of task A.

Some disagreement here again.  I agree that number 1 and 2 above do have
a lot to do with the performance of any individual task.  I don't
believe that number 3 has much to do with performance other than the
presence/absence of virtual memory.  Obviously, page swapping can impact
performance, but how can common vs. seperate address spaces, memory
protection affect performance?  I don't believe that loading MMU
registers can have much impact on performance.  Granted that MMU cache
entries will likely be invalid after a task switch, but then most (if
not all) locality of reference is lost on any task switch, be it
cooperative or pre-emptive.  This shows another area that could be
argued (but I believe it's not a valid argument).  Higher _system_
performance could be gained by not doing pre-emptive task switching,
since the processor cache hit rate should be higher if a task is allowed
to run until it can't anymore (due to I/O needs).  The cache could be
unnecessarilly made invalid (due to losing the locality of reference) by
pre-emptive task-switching.

Just some more fuel to add to the multi-tasking fire.  Seriously though,
I really wish people weren't so hung up on pre-emptive multitasking.  I
agree it's the way to go on the Mac (in the future), but people should
recognize that cooperative multitasking is a perfectly legitimate method
of multitasking.  There is only one reason for implementing cooperative
multitasking -  when the process state can only be known at certain times.
This is the case with the current Mac O/S.  When Apple is able to better
define process state, either by keeping all process state information in
one place, or by providing a virtual machine capability, that's when
we'll see pre-emptive multitasking on the Mac.


Jay O'Conor
jay@maspar.com