Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!yale!eagle!jtreworgy
From: jtreworgy@eagle.wesleyan.edu
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Message-ID: <376@eagle.wesleyan.edu>
Date: 7 Aug 89 09:32:14 GMT
References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com>
Lines: 40

In article <1989Aug4.173233.8259@sj.ate.slb.com>, greg@bilbo (Greg Wageman) writes:
[....]
> 
> All of the above is true in general, *but*, the implementation of task
> scheduling varies from OS to OS and will greatly effect how fast the
> machine appears to the user.
> 
> 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.
> 

I don't program the Amiga at a low level, so I don't know exactly how it works.
I do know, however, that if I am running a task which has a higher priority
than the CPU-intensive task, I NEVER have sluggish response from the foreground
task. Try it sometime and see for yourself. 

-- 
James A. Treworgy               "You should have seen me with the poker man,
jtreworgy@eagle.wesleyan.edu     I had a honey and I bet a grand,
jtreworgy%eagle@WESLEYAN.BITNET  Just in the nick of time I looked at his hand"
Box 5033 Wesleyan Station                           -Paul McCartney
Middletown, CT 06475