Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!mit-eddie!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Re: Mac Multitasking? Hee-hee!
Message-ID: <7624@think.UUCP>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: think.7624
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Fri, 21-Aug-87 02:33:47 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp> <4537@videovax.Tek.COM> <20164@ucbvax.BERKELEY.EDU>
Sender: news@think.UUCP
Reply-To: barmar@godot.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 51
Xref: mnetor comp.sys.amiga:7537 comp.sys.mac:5691

In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
[description of why preemptive multitasking causes long lags when an
idle interactive task is restarted]
>
>Amiga fans can help not by explaining why multi-tasking is good, but
>by explaining how the Amiga can do multi-tasking without suffering
>from the interactive response problems that plague Unix, VMS, and that
>plagued the Lisa.

I don't have an Amiga, but I think the reason it doesn't suffer from
the problems you describe is that it doesn't page.  The problems you
described have nothing to do with whether multitasking uses a
preemptive or synchronous scheduler.  If an inactive task is paged
out, there will be a long delay paging it back into memory in either
case.

And if you have to wait 3-4 seconds for your Sun to restart an
inactive process, you must be running some huge applications or you
don't have enough memory, as I've never seen a Sun pause that long.
Most of the time switching windows seems to be spent redrawing the
window (redrawing the previously-hidden parts, fixing up the border
objects).  Or maybe the Sun 3/50 is smaller than I think (I think most
of our Suns here are 3/140's and 3/280's).

The main thing that would slow down preemptive multitasking on the Mac
is the lack of an MMU.  Without this, the system must copy all the low
memory globals of one task to somewhere else in memory and then copy
in the globals of the new task.  With an MMU it can simply adjust the
segment registers to point to the new task's globals.  Globals common
to all tasks (such as screen memory) would be pointed to by a
different segment register that wouldn't be updated.

Macintosh background tasks simply don't expect to have their own
private set of low memory globals.  They lock down some space in the
all-task common area (currently the system heap), and they are able to
run no matter which foreground task is currently in control.  If they
want to run more often than the foreground task calls GetEvent, they
can put themselves on the VBL queue, so they will run as often as 60
times a second.

An MMU will soon be available for the Mac II.  Initially it will only
be used by A/UX.  However, I am sure that it won't be too long before
someone (Apple, Andy Hertzfeld, someone new) figures out how to use it
to make the normal Mac OS have preemptive scheduling.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar