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)