dwb@Apple.COM (David W. Berry) (03/17/88)
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.
peter@nuchat.UUCP (Peter da Silva) (03/19/88)
In article <7720@apple.Apple.Com>, dwb@Apple.COM (David W. Berry) writes: > A quick summary of pro's and con's of preemptive and nonpreemptive > multitasking: A few comments based on the fact that you're comparing yourself to a non real-time operating system. For single-user use, a real-time operating system (like Amiga's Exec) addresses virtually every complaint you have with concurrency. > 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. On a machine without memory protection, task switches can be as simple as: timer interrupt occurs in the context of the old task. push all registers on old task's stack. pop all registers off new task's stack. return in the context of the new task. > 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. So you use semaphores or formal messages to synchronise things. On UNIX this is handled invisibly by the kernel: a task switch occurs under control of the operating system. On the Amiga, which has a much more complex shared memory environment, you use semaphores or use standard library calls that do the semaphoring for you. I don't care that DrawImage does WaitBlits and OwnBlits and LockLayers and stuff. > 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. Nope. Never had any problew3ms with that. The mouse motion is under control of a high-priority realtime task called "Intuition". > Program control > Nonpreemptive multitasking gives the program much more precise > control of when it get's switched. Not at all. I can keep from getting switched any time I need to: Forbid(); Do something that needs to be atomic. Permit(); > 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. If the tasks are I/O bound they'll be spending most of their time on the wait queue. If they're CPU bound you can always knock their priority down a peg. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
ralph@computing-maths.cardiff.ac.uk (Ralph Martin) (03/21/88)
Posting-Front-End: GNU Emacs 18.47.1 of Mon Nov 23 1987 on v1 (berkeley-unix) I'm afraid you guys at apple have shot your self in the foot. By saying that applications such as excel POLL for events during long calcultions, you have hit the real nub of the matter. In a "real" multitasking operating system, the operating system takes care of events via interrupts, and deals with them accordingly - even while other things are going on. A second thing the OS does is to handle memory management. On the mac, the poor programmer has to worry about handles, and relocation blowing him away. Lets face it, the Mac is a machine with a brilliant user interface, but no real operating system worthy of the name. I much prefer to use my mac to my sun, but I LOATHE programming it. On the sun, part of the OS (the notifier) takes care of events and calls the bits of code I want in response to the events. On the Mac, I have to ask all the time what is going on, figure out if I want it, and give it back to the system if I dont, and so on, as well as looking after memory management too. This has two serious upshots (1) Mac programs are much more likely to crash - there is no overall way of ensuring programmers manage memory in a sensible way, (2) If programs don't both to poll, they screw the user up if he wants to switch (juggle), and so on. In my opinion, much of this garbage should be pushed out of the control of the programmer, for the benefit of all concerned. I can well believe the rumours that the Mac OS is being written.
tvillan@hpccc.HP.COM (Tim Villanueva) (03/29/88)
>I'm afraid you guys at apple have shot your self in the foot. >In a "real" multitasking operating system, the operating system takes care of >events via interrupts, and deals with them accordingly - even while other >things are going on. . . . [Description of Mac OS inferiority's deleted] Hear Hear! I agree. Programming on the MAC is torture, and no fun. Programming on MS-Windows is MUCH easier and makes much more sense. (I'm not saying that MS-Windows is better than Mac, only that programming under it is!) --------------------------------------------- Tim Villanueva "My comments are my own Hewlett-Packard (Personal Software Division) and not those of any 408-773-6268 Mailstop: 81UO other entity, especially tvillan%hpccc@hplabs.HP.COM the one I work for!" ---------------------------------------------