Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Re: Mac Multitasking? Hee-hee!
Message-ID: <20164@ucbvax.BERKELEY.EDU>
Date: Tue, 18-Aug-87 21:14:53 EDT
Article-I.D.: ucbvax.20164
Posted: Tue Aug 18 21:14:53 1987
Date-Received: Thu, 20-Aug-87 06:36:47 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp> <4537@videovax.Tek.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 66
Xref: mnetor comp.sys.amiga:7535 comp.sys.mac:5682

Most Macintosh owners who read these news groups have a perfectly good
idea what multi-tasking is. After all, the software that hosts "news"
generally runs on big, multi-tasking machines. So, Amiga owners, you
don't have to keep explaining how wonderful it is.

Now some substance: Most time-slice mutlti-tasking operating systems
guarantee that every ready-to-run job will get a chance to run, at
least once a time-interval (often a second.) This has the effect of
slowing down interactive performance: the interactive application
doesn't get all of the processor, so there is a lag in its response to
user input. Time sharing multi-user operating systems (like Unix) are
built on the premise that the user will ignore the lag. But, users
used to a single process environment get very picky about the fine
time structure of responsiveness. Example: "If it used to begin to
respond in 3/5ths of a second, and now it takes 4/5ths of a second,
even if it finishes in half the old time, it will feel sluggish."

Here is a problem that neither the current Mac or Amiga have, but may
hurt them both in the future:
Virtual memory interacts poorly with time-slicing and interactivity:
If you have time-slice multitasking, there will often be big low priority
jobs running in the background, while there is an interactive job
responding to the user. As the user stops to think, the interactive
job has nothing to do, so the background job gets most of the CPU. As
the background job runs, it pages in its working set, and as the
background job is paged in, the interactive job is paged out.  Now the
user starts typing or mousing again.  The interactive job must be
retrieved from the paging disk, and the user has to wait for that disk
before his clicks are responded to. On a Sun 3/50 running X and Unix,
this process can take 3 or 4 seconds. That is, clicking on a different
window can mean a pause of as much as 3 or 4 seconds before the new
window is ready to listen to key-strokes (Until it is ready, X will
send the keystrokes to the old active window.) 

Pauses, lags, and unpredictable response time all contribute toward
making even a fast system seem slow. Apple had a multi-tasking
operating system back in '81. It was called the "Lisa Office System",
and suffered from all of the responsiveness problems I've outlined.

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.

The Macintosh has always had event-driven multi-tasking, as opposed to
time-slice. I have written many programs that run as background tasks.
It is just that on the Mac, the interactive application must
explicitly give up control (which it only does at times that are not
critical to the perception of responsiveness.) All the major Macintosh
applications do give up control to background tasks. To see this, run
my "Menu Clock". If the colon between the hour and the minutes display
blinks, then the application is giving up control to the clock.

The new announcements of multi-tasking by Apple, are beacuse the new
Macintoshes, unlike the 128K original Macs, have enough memory that
more than one interactive application can comfortably reside in main
memory at once. Apple has used the old give-up-control mechanism,
already built into most Macintosh applications, to let applications
give up control, not to small background tasks, but to each other.
Since we already could cut and paste between applications, this means
that the user can pick a group of applications and have them work as a
seamless whole.

--- David Phillip Oster            --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu