Xref: utzoo comp.sys.mac:14020 comp.windows.misc:299
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!zeus!bobr
From: bobr@zeus.TEK.COM (Robert Reed)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <3268@zeus.TEK.COM>
Date: 16 Mar 88 02:22:33 GMT
References: <3255@zeus.TEK.COM> <3760@bloom-beacon.MIT.EDU>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 60

In <3760@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes:

    ...let me summarize what I got out of it:

    Robert Reed defines a preemptive multitasking system as one in which
    tasks are switched automatically after a fixed time.  

Not quite.  A preemptive multitasking system does not require time-slicing.
Preemption can also be implemented as a part of system I/O calls, as
exemplified in my last message.

    Let me assume we have an NPM system where tasks switch only when they
    give up control, presumably by means of some Wait function.  (I can't
    think of another kind of NPM system offhand.)

    (1) Can tasks run independently?  I would say no, because every other
    task is _dependent_ on the current task calling Wait.  If the current
    task never calls Wait, because of an infinite loop or some kind of
    crash, then no other task will ever get to run, am I right?

Task independence comes in many shades.  You can write a preemptive
scheduler in which smaller tasks get a higher priority, and by varying the
parameters, effectively lock out larger tasks.  Are the larger tasks then
dependent on the smaller ones?  Well, in a sense, yes.  Yet the tasks
themselves are independent of each other and we still have multitasking.

    (2) Can tasks communicate?  The current task can certainly leave
    messages for other tasks.  The other tasks won't be able to reply until
    the current task calls Wait, but I'll grant that this is communication.

Again, interprocess communication is NOT a prerequisite for multitasking.
Consider a batch processing system which has a mix of jobs that can be run
in any order.  No interprocess communications are required or even expected,
yet the system is truly multitasking, with distinct jobs running
simultaneously.

    (3) Can tasks interrupt each other?  Again, the current task could
    probably do something to make sure some other task doesn't get called
    again.  I would hesitate to call this interrupting, but the real problem
    is that no other task can ever interrupt the current task.  This is
    really the same problem as (1).

Task interruption is a subset of interprocess communication, and is not
required for a multitasking system.  Yet a task interruption system can be
constructed, even using nonpreemptive scheduler, assuming well behaved
processes.  It may not be very useful as a program development environment,
because of the issues you've raised.  Still, that does not exclude it from
the domain of multitasking systems.

    If you accept my definition of multitasking, I think you cannot avoid
    concluding that the Mac with MultiFinder is not multitasking.

    Definitions can only be used by consensus.

This is the crux of the issue.  In your narrowed view of multitasking, IPC
requirements may exclude such systems as Multifinder.  Yet, Multifinder fits
broader views of multitasking which rely only on the ability to share
resources among a set of simultaneously executing processes.  
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK