Path: utzoo!utgpu!watmath!watdragon!dahlia!swklassen
From: swklassen@dahlia.waterloo.edu (Steven W. Klassen)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Summary: Multitasking lesson one
Message-ID: <15627@watdragon.waterloo.edu>
Date: 3 Aug 89 16:18:06 GMT
References: <8908021826.AA05333@ucbvax.Berkeley.EDU>
Sender: daemon@watdragon.waterloo.edu
Reply-To: swklassen@dahlia.waterloo.edu (Steven W. Klassen)
Organization: U. of Waterloo, Ontario
Lines: 49

In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes:
>It drives me nuts to see so many people worrying about multitasking on the
>ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble
>getting good performance running one application at a time. If a CPU intensive
>app is running, I do not want to make it crawl any slower by asking the CPU
>to service another application. Hell, most people crave multitasking but until
>you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't
>worth worrying about for 99% of the users.
>
>Want to run a word processor and a spreadsheet at the same time. No problem,
>get REVOLVER and switch between apps. Want to generate huge dbMAN reports
>and run .CMD files while executing another CPU intensive app - forget it!
>
>Jumping between apps is OK on the ST. Running multiple, CPU intensive apps
>is silly.
>
>Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I
>know this will spark a "look at me" response but I'm talking widespread use
>of multitasking, not isolated examples)?

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]

The basic idea (when related to a single user system) is that if you have
one high priority (main) process and one or more lower priority processes
the lower priority ones will only run during the times that the high
priority one is not.  For example, in a database program a LOT of the
run time is spent doing nothing but waiting for user input.  A lot of
machine instructions can be executed by an 8Mhz processor during a, say,
one second pause at the keyboard.  Hence while the high priority process
is waiting the low priority processes can run, being interrupted when
the high priority one is ready again.

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.


Steven W. Klassen
Computer Science Major
University of Waterloo