Xref: utzoo comp.sys.mac:14080 comp.windows.misc:314 Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!agate!aurora!labrea!decwrl!nsc!voder!apple!dwb From: dwb@Apple.COM (David W. Berry) Newsgroups: comp.sys.mac,comp.windows.misc Subject: Re: Preemptive and Nonpreemptive Multitasking Message-ID: <7720@apple.Apple.Com> Date: 17 Mar 88 06:54:25 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> <1174@cpocd2.UUCP> Reply-To: dwb@apple.UUCP (David W. Berry) Organization: Apple Computer Inc, Cupertino, CA Lines: 90 Keywords: window human computer interface In article <1174@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes: > >>What I said was that MultiFinder still had some known areas where it >>could be improved. Not that it was less than multitasking. As >>a matter of fact it is fully and completely multitasking, non- >>premptive, but multitasking all the same. Especially when one >>considers that all macintosh programs should be calling GetNextEvent >>periodically to interact with the user anyway, and task switching >>is done there. > >You can see the problem but still don't admit it's there? In real multitasking >NO SPECIAL CODING IS NEEDED. Most programs multitask AUTOMATICALLY without any >special attention from the programmer. > >Under MultiFinder, each program (except possibly the last one) must be >specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead >of GetNextEvent (if I don't have them reversed). Why is this a problem? >Because it only takes one or two programs which fail to do this before >MultiFinder fails to grant any CPU time at all to the lowest priority task. >Why is this a problem? Because there are lots of Mac programs out there which >were written before MultiFinder and are still useful, but which will never be >changed. Companies go out of business. Shareware authors move on to more >lucrative pursuits. Etc. Ahh... But what you're missing is the fact that almost every application that exists for the Macintosh already periodically calls GetNextEvent. Like every time it want's input from the user. Task switches are performed on calls to GetNextEvent, WaitNextEvent and, I believe, EventAvail. Therefore almost every Macintosh application already allows task switches at fairly frequent intervals. No recoding necessary. No extra work necessary. In fact, applications such as Excel already periodically poll for events during long calculations such as recalculating the spread sheet to allow the user to scroll to a more useful portion, change more values, etc, and still have real response. These applications continue to work as well or better. WaitNextEvent isn't a necessity for task switching. It's a nicety which allows a task to more completely specify what kind of tasks it's interested in. A quick summary of pro's and con's of preemptive and nonpreemptive multitasking: 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. Programmer Ignorance: With preemptive multitasking the programmer can be completely ignorant. He doesn't have to think about the fact that this calculation is going to take three days and some other task probably ought to run during that time. Runaway or inconsiderate programs: 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. 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. 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. 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. -- David W. Berry dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did.