Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!lll-winken!uunet!philmtl!philabs!linus!mbunix!rachamp From: rachamp@mbunix.mitre.org (Richard A. Champeaux) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking on the ST Summary: No performance degradation on the Amiga. Message-ID: <63138@linus.UUCP> Date: 8 Aug 89 12:48:33 GMT References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com> <376@eagle.wesleyan.edu> Sender: news@linus.UUCP Reply-To: rachamp@mbunix (Champeaux) Organization: The MITRE Corporation, Bedford, Mass. Lines: 52 >In article <1989Aug4.173233.8259@sj.ate.slb.com>, greg@bilbo (Greg Wageman) writes: >> Typically, a task cannot be suspended in a multitasking environment >> until one of two things happens: it makes an operating system call >> which must wait for an external event (such as an "operation >> completed" interrupt) and is then put into a "blocked" state by the >> OS; or, in time-sliced OS's, its time quantum expires. Some real-time >> multitasking kernels do not require time slicing, so blocking calls are >> the only way a task switch ever occurs. >> >> The implication is that if the so-called "background" process is doing >> something CPU intensive(e.g. an in-memory sort), it may not make a >> blocking call for a very long time (i.e. several seconds). The user >> will begin to type characters, generating an interrupt which will >> unblock his foreground task. The OS will move the now-unblocked >> foreground task to the "ready" task queue, but it *will not begin to >> run* until the background task blocks (or its time quantum expires). >> If the system clock is grainy enough (i. e. the clock "tick" interval >> is very large), or a task context-switch is very expensive, or (yuck!) >> both, hundreds of milliseconds will elapse between the user's keypress >> and the resumption of execution of the foreground task. Thus, the >> user will perceive a very sluggish response from the foreground task. >> From The Amiga ROM Kernel manual: Every task has an assigned priority and tasks are scheduled to use the processor on a priority basis. The highest priority ready task is selected and receives processing until: 1. A higher priority task becomes active. 2. The running task exceeds a preset time period (a quantum) and there is another equal priority task to run, or 3. The task needs to wait for an external event before it can continue. Task scheduling is preemptive in nature. The running task may lose the processor at nearly any moment by being displaced by another more urgent task. Later, when the preempted task regains the processor, it continues where it left off. When a higher priority task becomes active, the running task is immediately interrupted. A task would become active if, for instance, it was waiting for a key to be pressed and the user pressed one. There would would be no degradation in response by a CPU intensive task if that task has a lower priority. Time slicing occurs only within groups of equal priority tasks. In fact, if a CPU intensive task was a higher priority task than other tasks, those tasks would be starved by the CPU intensive one. Last night I ran a raytrace at a lower priority than my Command Line Interpreter and saw no performance degradation. Even when I just mashed my hands down on the keyboard there was no sluggishness. Rich Champeaux (rachamp@mbunix.mitre.org)