🚀 go-pugleaf

In article <9430@cbmvax.cbm.commodore.com.commodore.com> mitchell@cbmvax.cbm.commodore.com.commodore.com (Fred Mitchell - PA) writes:
>In article <1990Jan13.105048.11530@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes:
>>
>>MultiFinder has been accused of not having "true" multitasking,
>>in that it requires applications to cooperate and not hog
>>the CPU to themselves.
>>...
>>In summary, a personal computer system needs *cooperative*,
>>not competitive, multitasking, ...
>
>I _very strongly_ disagree. On the Amiga, you have the best example of
>pre-emptive multitasking that I have ever seen on a micro. And the number
>ONE thing that you have is SPEED! If my program dosen't have to make
>repeated calls to the OS, it can run that much faster. I don't see any
>advantages to having a 'cooperative' OS at all. It tends to get in the way,
>and hints at a fundamental flaw in the initial design. I fail to understand
>why Macs can't go pre-emptive anyway. All you do is save all the registers,
>go to the next task, and load that task's registers, and hop right in where
>it left off before! Shared resources can use semaphores to arbitrate usage.
>Sound pretty simple to me! Why is that not possible under the Multi-Finder (or
>Finder for that matter)?  :-(

Sigh... Will this never end?  For nearly 10 years I was an O/S Software
Engineer for a company that had it's own proprietary COOPERATIVE multitasking
O/S.  It is _very_ possible to have an effective, efficient cooperative
multitasking O/S.  In terms of efficency, a cooperative multitasking
scheme has less overhead since processes aren't being switched while they have
useful work to do.  In terms of effectiveness, no application had any effect
on the response of another.  It worked well because the system was very I/O
intensive.  All this I/O time was available for other processes.  Badly behaved
applications that didn't release the CPU were detected very quickly during 
development.  Only one application (the assembler) had O/S calls inserted in
the code to explicitly give up the CPU.  This was the most CPU intensive
application on the system.
It is not as simple to implement a preemptive multitasking O/S as you indicate
above.  The entire state (context) of a process must be saved between process
switching.  Unfortunately, the processor registers are not all of the process
context.  On the Mac, currently the only place where a process state can be
guaranteed to be stable is at the process switch times Apple has defined for
MultiFinder (GetNextEvent, WaitNextEvent, etc.).  Even the UNIX kernel doesn't 
preemptively switch processes while executing in the kernel.  It doesn't need
to - perfectly reasonable response can be acheived without it.  But it does
interfere with Unix's abiltity to be a real-time O/S.  I point this out to
illustrate that even what many people consider to be the foremost preemptive
multitasking O/S isn't perfectly preemptive.  But people don't complain about
Unix (unless they want a realtime O/S).
All this is not to say that MultiFinder is perfect.  Flaw number one is that
processes don't switch during disk I/O.  Even if they did, I'm not sure how
effective that would be without DMA.  Flaw number two is that all output to
the display is very CPU intensive - obviously.  In a serial terminal based 
system, a cooperative multitasking O/S can service other processes during 
screen updating - the Mac can't.  
Instead of debating the merits of preemptive vs. cooperative multitasking
O/Ss, why not debate the issues that would make the Mac a more effective
multitasking system regardless of the policy used - THE MAC NEEDS DMA AND
A QUICKDRAW COPROCESSOR.  Let's identify wasted CPU time and gripe about
how that time isn't being given to other processes.
On a similar note, some people on the net have griped about how the Mac
doesn't have (and won't, even under 7.0) _protected_ virtual memory.
How about getting a discussion about this going.  I understand _why_ it's
going to be difficult to implement seperate protected address spaces for
processes - the question is what is going to be done to the Mac O/S to 
overcome these hurdles in the future.  One problem that has to be taken
care of are data structures (such as the window list) that currently
logically thread their way through what would be all process address spaces.

>
>>...not as a cut-down version of a multiuser operating system. I
>>think even round-robin time-slicing (forced periodic rescheduling)
>>of tasks is a bad idea; it costs CPU cycles to implement,
>
>Not nearly as much as cooperative costs you!

False.  Cooperative costs LESS if implemented correctly.
See above.  The Mac needs to have more time spent waiting for I/O.

>
>Then again it's unfair to compare a personal computer to a multi-user
>system. (Or is it? :-) 

The boundaries are blurring.  The one boundary that I hope will remain
intact is that personal computers are not shared by multiple people at
the same time.  I'd like to see the Mac evolve into an efficient multi-
tasking system, not a multiuser system.

(now getting down off my soapbox :-) )

>
>	-Mitchell
>	 mitchell@cbmvax.UUCP


Jay O'Conor
UNIX O/S Sofware Engineer
Unisys/Convergent