🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #26355

Re: A/UX window systems, Mac tool...( Hum Interface)

#26355
From: Adam Kao
Date: Tue, 15 Mar 1988 06:57
79 lines
4498 bytes
In article <3255@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes:
>BSD without TCP/IP and sockets would still be multitasking, yes?

Oh boy.  You just left me in the dust.  I confess, I'm not a Unix
wizard.  Please explain?

It was very difficult for me to understand this posting.  Forgive me
if I err, but 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.  If I have this
right, this is also called time-slice multitasking, isn't it?  In this
case a non-preemptive multitasking system would be one in which the
passage of time does not force tasks to switch; instead some other
mechanism is used, like the tasks themselves explicitly giving up
control.  In all other respects preemptive and non-preemptive
multitasking would be identical.

Mr. Reed continues with several examples of systems that would be
difficult to classify using my definition.

Please bear with me as I examine Mr. Reed's definition of
non-preemptive multitasking (NPM) in light of my definition of
multitasking.  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?

	(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.

	(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).

Therefore, by my definition, this kind of NPM is not multitasking.

Now I must inject some philosophy about Definitions.  Definitions
are constructs that people agree to use for communication.  They ease
discussion in that, when accepted, everybody has a better idea of what
everyone else is talking about.  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_.  If you do not accept my
definition of multitasking, there is nothing I can do.  My argument
about the Mac and MultiFinder becomes much more complicated.  We can't
argue ABOUT my definition; you either accept it or you don't.

Definitions are _artificial_.  Reality is infinitely complex, all
things are related to all others, every rule has an exception.  Every
Definition we make must necessarily be a simplification.  We think of
Definitions as walls with which we categorize things, but there are
always cases that sit on the fence.  This does NOT make Definitions
useless; we may not know where exactly the atmosphere stops and space
begins, but you damn well better know the difference between standing
on the Earth and standing on the Moon.  Similarly, I don't see the Mac
and MultiFinder as any kind of fuzzy case.

>							So there IS more
>between heaven and earth than dreamt in your philosophy.

I agree completely.

Again, if I have misinterpreted Mr. Reed's posting in any way, I
apologize, and hope I will be corrected very quickly.

>-- 
>Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK

Adam
Technical Details
Message-ID: <3760@bloom-beacon.MIT.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-tis!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!chekmate
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <9829@steinmetz.steinmetz.UUCP> <7593@apple.Apple.Com> <3609@bloom-beacon.MIT.EDU> <7658@apple.Apple.Com> <3691@bloom-beacon.MIT.EDU> <3255@zeus.TEK.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-tis!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!chekmate
From: chekmate@athena.mit.edu (Adam Kao)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <3760@bloom-beacon.MIT.EDU>
Date: 15 Mar 88 06:57:35 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <9829@steinmetz.steinmetz.UUCP> <7593@apple.Apple.Com> <3609@bloom-beacon.MIT.EDU> <7658@apple.Apple.Com> <3691@bloom-beacon.MIT.EDU> <3255@zeus.TEK.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: chekmate@athena.mit.edu (Adam Kao)
Organization: Massachusetts Institute of Technology
Lines: 78