Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!ames!sun-barr!texsun!convex!iex!athens.iex.com!cramer
From: cramer@athens.iex.com (Bill Cramer)
Newsgroups: comp.sys.mac
Subject: Re: Apple System 7.0
Message-ID: <870@iex.UUCP>
Date: 30 May 89 13:57:27 GMT
References: <17183@usc.edu> <4679@okstate.UUCP> <1925@internal.Apple.COM> <61086@yale-celray.yale.UUCP> <9344@polya.Stanford.EDU> <2097@ccnysci.UUCP> <18888@cup.portal.com> <16225@gryphon.COM>
Sender: news@iex.UUCP
Reply-To: cramer@iex.UUCP (Bill Cramer)
Organization: IEX Corporation, Dallas
Lines: 57

In article <16225@gryphon.COM> jspear@gryphon.COM (Jon Spear) writes:
[ etc about multitasking omitted ...]

>We're getting a bit far afield, but this reminds me of the first
>computer I was responsible for: a PDP 11/34 running Digital Standard
>MUMPS (DSM-11).  DSM-11 was a single-language (MUMPS) operating system
>built on top of RSX-11.  MUMPS is a concise interpreter-oriented
>language and environment convenient for building multiuser hierarchical
>database applications that was (is?) popular in the medical computing
>community. 
>
>Anyway... this appeared to be non-preemptive multitasking since a single
>compute-bound program did indeed lock the system up solid. (Of course
>you can do the same thing to a VAX/VMS system if any CPU hog has a high
>enough CPU priority, but MUMPS on a VAX couldn't normally do that.)
>
>My point? Other commercial operating systems from big name vendors have
>been successful (somewhat) even with non-preemptive multitasking.
>Further, having preemption does not guarantee no CPU starvation.
>
>-Jon

I've been amused at the whining in the MacRags over the issue of *real* 
multitasking for the Mac, and Jon makes a good observation here.  For a 
realtime application, the form of multitasking performed by DEC's RSX-11, 
as well as real time executives (MTOS, PSOS, VRTX, and the like) is 
infinitely better than the fair-share timeslicing most often called *real* 
multitasking.  In a realtime environment, it is a REQUIREMENT that tasks 
have the opportunity to complete processing of some event before they give 
up the CPU.  While the task is waiting on the next event (or I/O completion) 
the scheduler is free to give the CPU to another task.  Sounds to me alot 
like MacOS/Multifinder.

The biggest difference with a realtime multitasker and MacOS is that the 
former allows you to give priorities to different tasks.  Given these 
priorities, the scheduler can pre-empt a lower priority task when the 
higher priority task needs the CPU -- even when the lower priority task
hasn't completed the event it is processing.  Like MacOS, tasks running at 
the same priority CANNOT pre-empt each other.  (Priority manipulation, by 
the way, in the hands of the naive, often leads to very unhappy 
users --  "My Edit is infinitely more important than your Compile" etc).

Folks writing realtime tasks understand their OS -- they don't write tight 
loops in high priority tasks without knowing that some other task may starve.
Folks writing MacOS programs [usually] understand their OS -- they don't 
write tight loops without an occasional breather.  

So what is it that everyone seems to want?  Beats the **** out of me.  What
is it that everyone seems to need?  Well, I've been wrong before (twice 
already this year :-), but IMHO, we need well written programs that 
understand the concept of how MacOS works.  (And IPC, and email, and
virtual memory, and protected memory, and ...)

Bill Cramer
IEX Corporation
Plano, Texas
{uunet,convex,killer}!iex!cramer