Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!labrea!decwrl!nsc!voder!apple!tecot
From: tecot@apple.UUCP
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Tru Multitasking meaningless (was Re: Mac Multitasking? Hee-hee!)
Message-ID: <1500@apple.UUCP>
Date: Tue, 18-Aug-87 23:13:00 EDT
Article-I.D.: apple.1500
Posted: Tue Aug 18 23:13:00 1987
Date-Received: Fri, 21-Aug-87 04:49:34 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp> <4537@videovax.Tek.COM>
Reply-To: tecot@apple.UUCP (Ed Tecot)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 89
Xref: utgpu comp.sys.amiga:7115 comp.sys.mac:5068

I'd like to dump on the net about a pet peeve of mine:  "True Multitasking"
has just about as much meaning as "Politically Correct" and "Standard Unix".
In other words, it has no meaning.  What most everyone means to say is
"Pre-emptive Multitasking", that is, that the processor can be yielded to 
another process at any time.  For my sake, please refrain from using
that other term.

And now for my more "direct" comments:

Yes, MultiFinder is being billed as the first generation multitasking O/S
for the Macintosh.  And it is, in fact, multitasking.  It is not (currently)
pre-emptive.  However, for Macintosh, this is not important.  All standard
Macintosh applications already yield when MultiFinder is running.  No changes
needed.  Applications only need to be changed for two basic reasons:
1)  Applications which do dirty tricks such as modifying the window list
	directly
2)  Applications which want to be "MultiFinder friendly" will use WaitNextEvent
	instead of GetNextEvent to allow MultiFinder to allow do its job
	better.

>The important point about time-slicing is that it allows virtually *any*
>two (or more) programs to multitask WITHOUT requiring even one "trivial
>code change."  Thus, on a system with time-slicing, a Kermit download
>will co-operate with an editor quite nicely (especially if Kermit is
>running at a lower priority).  The editor will suffer no response
>degradation, while Kermit will run quickly almost all the time (editors
>usually spend a lot of time waiting for keystrokes. . .).

This should work on the Mac as well.  The reason:  If Kermit provides any way
to cancel the download, it is automatically ceding control.  Now I must admit
that some "trivial" changes are required, but they exist only because several
Mac applications (incorrectly) made the assumption that they would have full
control and do strange things like animating the cursor.  Although such
applications will run, they will look wierd and confuse the naive user.
All that is required is to place a resource in the application (no need to
recompile or even have the source code) so that MultiFinder will know that
it is not one of those "wierd" applications.

>The time savings from eliminating three enormous writes to disk and three
>correspondingly enormous reads from disk are tremendous.  Also, on small
>systems, there may not be enough mass storage to hold all the intermediate
>forms at once.  Thus, the user would have to delete intermediate files
>between steps, or operate from one disk to another (or both!).  On my
>Amiga, which has two floppy disk drives and no hard disk, this would tie
>up the system completely, as well as requiring my intervention at several
>places in the process.  But with the pipelined version, I would need to
>use only one disk (for output), so the second drive is freed for other
>purposes.

Great.  I think most of us are familiar with pipes and can see their benefit.
But pipes does not a multitasking system make.  It is related to a different
sub-topic: inter-process communication.  Please don't confuse the two.

>Further, because of the multitasking, I can still do a compilation in
>the background *and* edit a file while all this is going on!  (This
>assumes that I have boatloads of memory, of course. . .)  With process
>priorities chosen carefully (e.g., editor priority > download, etc.
>priority > compilation priority), the editor will be responsive,
>the download and associated processing will perk right along (limited
>mainly by the phone line data rate), and the compilation will use up
>whatever is left of the CPU.

On a Macintosh, these priorities are automatic, the user doesn't have to
carefully do anything.

>This is just one example of enhanced productivity and system utility
>provided by true multitasking.  None of the programs that are running
>need to know or do anything out of the ordinary in order to multitask.

Instead, the user takes the burden.  None of the programs that are running
need to know or do anything out of the ordinary in order to multitask on
MultiFinder either, it just so happens that some applications do things out
of the ordinary that prevent them from running cleanly in the background.

>Because it puts the responsibility for task switching on the programs
>themselves, so-called "synchronous multitasking" only works with programs
>designed to permit task switching.

But almost all of them do.

>Compared to true multitasking,
>"synchronous multitasking" is a feeble and limited technique.

Where's the proof?  I contend that synchronous multitasking is more efficient,
provided that the synchronization is transparent to the process (which is
true for MultiFinder).


						_emt