Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: multitasking and IPC (was: System 8.0: no more DA's.)
Message-ID: <27247@ucbvax.BERKELEY.EDU>
Date: 24 Dec 88 17:22:28 GMT
References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM> <807@esl.UUCP> <747@lts.UUCP> <34550@think.UUCP> <877@husc6.harvard.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 81

In article <877@husc6.harvard.edu> fry@brauer.harvard.edu (David Fry) writes:
>BUT if you hold the mouse
>down on a menu or scroll bar, the download will be
>interrupted.  This is the feature that I think shows the need
>for pre-emptive MT most clearly.  MultiFinder is super, given
>what it has to do, but I don't like calling $35/hour telecomm
>services, and then feeling afraid to scan the menu bar in
>another application for fear of wasting valuable download
>money.

o.) A terminal emulator that behaves this way is buggy! Download/Uploads
can be done quite comfortably at interrupt level, all except file i/o, and
that can be handled by buffering enough text for a minute or so of mousing
around.

o.) The Macintosh party line is that the computer must have the perception
of speed. Note, this is different from actually being speedy. For example,
Bill Atkinson told me that originally MacPaint drew directly to the
screen during mouse drags, but this caused flicker. He added off-screen
buffering to get rid of the flicker, and discovered that people percieved
the new version as running faster, because it was now smooth, when, in
fact, it was drawing to the screen less often than the previous version.

The Macintosh is multi-tasking. At this moment, I am using Menu Clock, a
task I wrote in '85. It has always used the multi-tasking that has always
been available.

It is just an Apple policy decision that user-interface intensive
tasks get >99% of the CPU, while they are running the user-interface.
(Only VBLs, sound, and device interrupts run during user-mouse tracking.)

The Lisa had multi-tasking, and was percieved as sluggish. The Macintosh
development team wanted their machine to seem faster, even though they
weren't using the fancy dual-ported RAM the Lisa had. Macintoshs through
the MacPlus gave about 30% of their CPU time up so the video controller
could get at the video RAM, so an 8MHZ 68000 in a Macintosh actually about
the same as the 6MHZ 68000 in the LIsa, when the effect of the dual ported
RAM was taken into account.

So, the Macintosh team made the rule, while the mouse is down, the user
gets the whole CPU.  Could you imagine trying to use a paint program, and
having a nice freehand line get screwed up because some task ate a lot of
CPU time in the middle of the stroke, causing the paint program to miss
mouse coordinates?

An alternative solution would have been, just throw more hardware in
the box. That was the route the Lisa took. Booting an Apple Lisa took
$10,000. worth of hardware at a time when booting a Macintosh took only
$ 2,500.

-----------------------

Most Unix programs ignore the problems of concurrent updates to the same
data files from multiple programs running in parallel. 

For example, one person edits the beginning of a long file, while
another person edits the end of that same file. Whoever saves their
changes last will wipe out the changes of the other.

And it is a hard problem in general, since a "transaction" may involve
changes to multiple files: Suppose I want to move something from file A to
file B. I read file A, make an in memory copy of the part of interest,
write the short file A. XXXX. Now, I open file B, write out the change,
and close it. At the time represented by the "XXXX" above, the amount on
disk is less than it should be. If a prowler program, say another user of
a file-backup utility, looked at both file a and file b at that time, it
wouldn't see any trace of the part that is in my local memory.

The Unix operating system gurantees that directories can be modified
cleanly, and the mail system gurantees that new mail can be delivered
while you are reading the old, But the designers of Unix said the
problem was too hard to solve in general, so they were leaving it to
the application authors.

As late as Version 7 of Unix, there was no information in the Unix
manuals on writing programs that could safely modify the same file in
parallel.

How should the Mac handle this problem?
One way is to add a new manager: the Database Manager, and have new
programs use it instead of the file manager.