Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gillies@m.cs.uiuc.edu
Newsgroups: comp.sys.mac
Subject: Re: Re: Re: Apple System 7.0, Amiga
Message-ID: <8400114@m.cs.uiuc.edu>
Date: 29 May 89 05:58:00 GMT
References: <18826@cup.portal.com>
Lines: 24
Nf-ID: #R:cup.portal.com:18826:m.cs.uiuc.edu:8400114:000:1280
Nf-From: m.cs.uiuc.edu!gillies    May 29 00:58:00 1989


/* 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