gillies@m.cs.uiuc.edu (05/29/89)
/* Written 12:14 pm May 28, 1989 by jspear@gryphon.COM in m.cs.uiuc.edu:comp.sys.mac */ > My point? Other commercial operating systems from big name vendors have > been successful (somewhat) even with non-preemptive multitasking. > Further, having preemption does not guarantee no CPU starvation. The PLATO system has used non-preemptive multitasking for over 20 years, with as many as 700 users at a time (on 4 CDC 6400's). This system is programmed in TUTOR, a threaded interpretive language, and when the interpreter is running, it checks for preemption after every statement executed. When compiled code is running (expression evaluation), it checks for preemption during reverse branches. The system works great. Programs are limited to about 1% of a CPU. The only way to hog the CPU is to exploit the naive load-balancing, by sitting idle for several hours, until your cycle average is about .01% of the CPU, and then demanding 20% of the CPU for a few minutes until your average goes back up to 1%. This could be easily fixed in the scheduler, but it has never been identified as a problem. Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
mcdonald@uxe.cso.uiuc.edu (06/01/89)
Subject is multitasking: >So what is it that everyone seems to want? Beats the **** out of me. What >is it that everyone seems to need? Well, I've been wrong before (twice >already this year :-), but IMHO, we need well written programs that >understand the concept of how MacOS works. (And IPC, and email, and >virtual memory, and protected memory, and ...) What people want in multitasking is real multitasking. That means that one task hogs the system resources IF AND OMLY IF the user (we are referring here to single user systems - in multiuser, it means the operator) tells the system that he wants that task to hog the system. It means that the user can stop a runaway task - by hitting some control key or sequence, assuming that he wasn't dumb enough to set the runaway task's priority higher than the task that services the key interrupts. It means that if a programmer makes a boo-boo and codes (in C, lets say, while(1); or label1: goto label1; ), that he can stop it. It means that if an errant program executes a WAIT_UNTIL_AN_INTERRUPT_HAPPENS instruction, that the OS checks to make sure that some interrupt is enabled (i.e. a disk read waiting to complete, or checks that the keyboard interuupt is working). It is hard to see that non-premptive multitasking can do all these things. OF course nothing will help if the OS kernal screws up. Doug McDonald