Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!rochester!bbn!cc5.bbn.com!denbeste From: denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste) Newsgroups: comp.sys.amiga,comp.sys.mac Subject: Defense of multi-tasking response Message-ID: <407@cc5.bbn.com.BBN.COM> Date: Wed, 19-Aug-87 09:37:14 EDT Article-I.D.: cc5.407 Posted: Wed Aug 19 09:37:14 1987 Date-Received: Sat, 22-Aug-87 00:45:02 EDT Organization: Bolt Beranek and Newman, Cambridge, MA Lines: 125 Xref: mnetor comp.sys.amiga:7548 comp.sys.mac:5712 > Now some substance: Most time-slice mutlti-tasking operating systems > guarantee that every ready-to-run job will get a chance to run, at > least once a time-interval (often a second.) This has the effect of > slowing down interactive performance: the interactive application > doesn't get all of the processor, so there is a lag in its response to > user input. OK, I don't like "my computer can beat up your computer" discussions any more than anyone else, so I will confine myself to theoretical discussions. First I'd like to point out that when multi-tasking, not every job is actually run-bound. The typical multi-tasking system maintains several queues with process control blocks. One is used to hold PCB's which aren't currently active, another to hold PCB's whose jobs are ready to run (usually known as the READY queue) and there will be an additional queue for each system resource (usually I/O devices) which a process may need but not be able to get. In many such systems, these queues are sorted by priority - particularly the run queue. (This is more-or-less how pSOS does it. pSOS is a helluva fine product.) On each time slice, the task switcher takes the item from the front of the run queue and moves it to the back (of its priority level) and takes the next one and lets it run. This takes the same amount of time unrelated to how many PCB's there are - so system overhead doesn't increase with a larger number of tasks. If there are several tasks operating at the same priority level, they each get an equal share of the machine, as you would expect. In this case, each operates slower than they would if they owned the machine. If there are several tasks which are READY, but one has a higher priority than any of the others, then it AND ONLY IT runs continuously. On each time slice the task switcher turns it on again. There lies the key to solving Mr. Oster's objection. Suppose I have an editor and a compilation running simultaneously. The editor is set to a higher priority than the compiler, but spends most of its time I/O bound. The user is examining the screen and not hitting the keys. On each time slice, the only task which is ready to run is the compiler, so it runs full tilt. The Editor is stuck on the I/O queue for the keyboard. The user hits a key - causing an interrupt. The interrupt handler takes the key, puts it in the key-press queue, and moves the Editor from the Keyboard queue to the READY queue. Note that it retains its higher priority. On the next time-slice, the task switcher gives the Editor a chance to run. It continues to be the only task at its priority which needs to run until it finishes handling the keystroke and goes I/O bound again, at which point it moves off of the READY queue back to the I/O queue for the keyboard. At that point, the compiler kicks in again and runs full tilt. (There can be variations on this theme if the keystroke causes other I/O - it may move the editor onto the disk queue, or the screen queue, or who knows what. Let's keep it simple for this discussion, though.) The practical effect of this is that the user of the editor gets exactly the same performance as he would if the compiler wasn't running - for the the following reason: If there isn't a low-priority task waiting to eat the CPU cycles which the editor doesn't need, the system has one which will, usually called "IDLE" or some such. The scenario described above is EXACTLY the same if the editor is the only task running, except that for "compiler" substitute "idle process". In some systems the task-switcher is invoked immediately after the READY queue is changed instead of waiting for the next time slice. This is what pSOS does; I don't know which approach the Amiga uses. All of this assumes that the user sets up the priorities correctly. On some systems it is done automatically by making any process which comes off an I/O queue be slightly higher priority for a couple of slices. Here we get into the black magic of scheduling algorithms, and risk losing our souls to some dark anti-deity. The Amiga does not do this automatically, but there is a command which allows it to be done manually. > Amiga fans can help not by explaining why multi-tasking is good, but > by explaining how the Amiga can do multi-tasking without suffering > from the interactive response problems that plague Unix, VMS, and that > plagued the Lisa. Most of the problems that plague UNIX and VMS come from the fact that often the number of highest-priority tasks which are READY are in total larger than the available memory - so even to service the READY queue requires memory swapping. The Amiga (and OS9, too, for that matter) avoids this by simply requiring that all tasks be memory resident at all times. If an MMU is available for the A2000 in the future, this requirement will probably still be maintained - so virtual memory shouldn't affect performance. This isn't a particularly major restriction with memory prices so low these days... Any remaining problems with interactive response can be handled by making any non-interactive tasks low priority on the Amiga. With regards to the LISA, I honestly don't know enough about it to be able to say what its problems are. I was able to run multi-tasking on my 900 Khz 6809-based Color Computer with OS9 quite reasonably with the maximum-possible-memory 64K, so I suspect that the LISA's problems came from bad design or bad implementation, not from any inherent difficulty in multi-tasking per se. > --- David Phillip Oster --My Good News: "I'm a perfectionist." > Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour." > Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu I have only one more comment: The presence of the capability of multi-tasking does not mandate its use. If a machine has it it can still be used in single-task mode if nothing else will do. If a machine is single-task, then multi-tasking cannot be used. Multi-tasking is not a solution to every problem, but it is a solution to many problems. It is an option I am glad I have on my Amiga. -- Steven C. Den Beste Bolt Beranek & Newman, Cambridge MA denbeste@bbn.com (ARPA or CSNET or UUCP) harvard!bbn.com!denbeste (UUCP) I don't think BBN cares what I think about this stuff.