Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.mac
Subject: Re: Preemptive and Nonpreemptive Multitasking
Message-ID: <8803171932.AA29989@cory.Berkeley.EDU>
Date: 17 Mar 88 19:32:54 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 104

>	A quick summary of pro's and con's of preemptive and nonpreemptive
>multitasking:

	In general, Dave's comments are true.  But there are extremely 
	simple solutions to most of the "problems" with preemptive
	multitasking.  I always view preemptive multitasking as a
	superset of nonpreemptive multitasking because you still have
	the capability to "turn off" the preemption thereby yielding
	the subset "nonpreemptive multitasking".  At least in microcomputers.
	convoluted OS's like UNIX are still in the dark ages as far
	as program control over multitasking goes.

>
>Task switches:
>	With non-preemptive multitasking task switches are simpler
>because you know the exact state of the machine when the switch
>occurs.  With preemptive you're never quite sure.

	The amount of code required to handle the difference is usually
	a couple of lines... Sometimes none.  Sometimes the additional
	code serves to add power that would otherwise not exist in
	a non-preemptive system.

>	With nonpreemptive multitasking runaway or inconsiderate programs
>can shut a machine down because there's no clean way to get control to
>kill them.  With preemptive multitasking they just eat CPU, but they can
>probably be cleanly killed.

	Here's a cute story:  Once, while writing a program on an Amiga,
	I created a real strange bug that 'hung' the task ... it went into
	an infinite loop.  It took me four tries to find the problem.  At
	the end, I had 4 tasks running in infinite loops while also doing
	the final compile (the one that fixed the problem).  

	I couldn't kill the tasks, but they didn't use much memory and
	I could lower their priority so they didn't effect the rest of
	the system.  So I could afford waiting until I got it right
	before rebooting to "clean up" the sytem.

>
>Indivisible operations:
>	Nonpreemptive multitasking makes indivisible operations a snap
>because the program is in control of when it let's go of the processor.
>With preemptive multitasking you're never sure when the processor will
>go away.

	Yes.  You have to think about it.  But most operating systems
	(micro computer OS's, at least) allow one to temporarily disable 
	task switching for critical operations.  Using the Amiga as an
	example, there are two exec calls: Forbid() and Permit() that
	do this.  The overhead for doing the call is essentially zero...
	they simply increment/decrement a certain location that exec
	looks at next time it wants to switch tasks.  This might seem
	counterproductive but it makes synchronization a snap.  You only
	do it for short (read: uS/mS) periods of time around the
	indivisible operations.


>Inopportune task switches
>	Preemptive multitasking allows task switches at inopportune
>times.  Ever have your windowing system lose the processor while your
>dragging something around with the mouse, makes for real jerky mouse
>movement.
>
>Program control
>	Nonpreemptive multitasking gives the program much more precise
>control of when it get's switched.

	I would disagree here.  This is where task priorities come in.
For instance, you place the window/mouse handler at a higher priority
than the application program.  Then, as soon as an event comes in (from
some interrupt service routine), the application program is preempted
and the window/mouse handler allowed to process the event.

	Thus, you get much smoother operation.  You might ask "what if
we had nonpreemptive multitasking instead"?  Then you are in even worse
shape!  The specific problem you mentioned is inherent in SUN workstations
because the mouse is handled by a process, and UNIX processes have huge
context switch overheads and braindamaged priority schemes.  The only
solution is to make the mouse handled by an interrupt or somewhere in the OS
rather than by a process.

>Fairness
>	Preemptive multitasking is in general "fairer" in that all
>tasks have a more or less equal chance of getting processor time.
>This can be modified by priorities, but no one process is going to
>get all the processor.  This is desireable in a multiuser timesharing
>environment.  It's a much less clear win in a singleuser environment
>since it means that tasks that I'm not clearly interested will be
>getting a fair share of the processor.

	Right, so you use a different priority scheme.  This has been
argued to death in comp.sys.amiga over the way the Amiga implements it.
Essentially, on the Amiga, a higher priority task shares the Cpu ONLY
with other tasks of the same priority (round robin).  Lower priority tasks
don't get a chance.  On the Amiga, application tasks run at the same priority
(0) so this doesn't cause problems.  Supervisors, managers, event handlers,
etc... usually run for only brief instances of time but want to run
as soon as some event happens, so are given higher priorities.  People
usually run demo's at lower priorities so they don't interfere with *real*
work.

>David W. Berry

				-Matt