Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!sjsca4!news
From: greg@bilbo (Greg Wageman)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Message-ID: <1989Aug4.173233.8259@sj.ate.slb.com>
Date: 4 Aug 89 17:32:33 GMT
References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu>
Reply-To: greg@sj.ate.slb.com (Greg Wageman)
Organization: Schlumberger ATE, San Jose, CA
Lines: 56

In article <15627@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) writes:
>
>In __THEORY__ multitasking does not have to slow down the processes.
>
>"A single user cannot, in general, keep either the cpu or the I/O
> devices busy at all times.  Multiprogramming [or multitasking if you
> prefer] is an attempt to increase cpu uilization by always having
> something for the cpu to execute."  [_Operating_System_Concepts_ by
> Silberschatz and Peterson, p. 18]
>
>Multitasking can actually speed up a program like a spreadsheet or a
>database by having the program written as a number of processes in
>which many of the 'housekeeping' tasks are done when the cpu is not
>otherwise busy.  In theory this can be done on any machine.  However,
>one which was designed with this in mind will do it much better than
>one which was not.

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.

The reference to a machine designed from the start for multitasking is
valid, because proper hardware design can minimize the expense of
context-switching, provide a suitably fine-grained system clock, and
include appropriate interrupt support for devices.  Trying to
retro-fit multitasking into a machine not designed for it is at best a
frustrating job whose results may not justify the effort.

Greg Wageman			DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies	UUCP:   ...!uunet!sjsca4!greg
1601 Technology Drive		BIX:    gwage
San Jose, CA 95110-1397		CIS:    74016,352
(408) 437-5198			GEnie:  G.WAGEMAN
------------------
Opinions expressed herein are solely the responsibility of the author.