Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!lbl-csam.arpa!antony
From: antony@lbl-csam.arpa (Antony A. Courtney)
Newsgroups: comp.sys.atari.st
Subject: Re: My last comments about ST multitasking
Message-ID: <3608@helios.ee.lbl.gov>
Date: 16 Aug 89 05:03:40 GMT
References: <8908160401.AA01009@ucbvax.Berkeley.EDU>
Sender: usenet@helios.ee.lbl.gov
Reply-To: antony@lbl-csam.arpa (Antony A. Courtney)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 70

In article <8908160401.AA01009@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes:
>I wish that some of the people who read and reply to net postings would
>actually take the time to understand what they have read. As an example,
>one reply about my original posting about MT on the ST went on-and-on
>about the move towards MT in the industry; hey!, I was NOT against MT, just
>puzzled why anyone would want it on a system like an 68000 at 8 MHz.

Right.  These people responded because it is important to note that with a well
written OS, things don't have to slow down, and generally don't.  Multitasking
adds functionality and versatility to any system.  And one of the fundamental
ideas behind most multitasking OSs is that things do not stop, they just slow
down.  Slowing down a little always beats stopping or exiting an application.

>In addition, so many postings came back giving examples of MT when they were
>just glorified task switching examples.
>
>MT to me means doing several CPU intensive jobs at the same time. It's not
>the ability to format a disk while you type in your word processor. It's
>not switching out of some game to do some spreadsheet work. It's not
>swapping data between painting programs. Those are all task switching examples.

Oh, Gee--So you define multitasking differently from everyone else in the world
and then say you don't think multitasking is a good idea?! :)

The conventional definition of multitasking as I have learned it is transparent
control by the OS over multiple execution streams.  Yes, this does involve
context switching, but the application never knows about the context switch
and is in fact not aware that it ever stops executing.  Each process thinks it
has the whole of the system's resources available to it.  And multitasking
implies a very fine granularity between context switches, such that if two
processes are competing for CPU time, it is extremely difficult to tell that
they are not both running concurrently.

> [ Example about not wanting to multitask while generating dbMan reports
>	because it would slow them down..]

As everyone else said: "Not if the other processes sleep pending some user
action like they are SUPPOSED to...."

>
>I reitierate, I am not anti-multitasking and I this is not a case of sour
>grapes (that's for you Amiga guys). I'll just wait until I can afford a
>machine that's got the guts to do real multitasking.
>

And your 68000 _HAS_ the guts to do multitasking.  And in some ways better
than a lot of other "Industrial" machines.  I'd be willing to bet that your
8 Mhz. 68000 can do a context switch faster than my Sun 4/280! :)

{For those technical-minded types who think I am exaggerating: the SpArc is a
RISC chip, meaning it has something well upwards of 200 32 bit registers. The
68000 has 14 32 bit registers.  Which do you think pushes them to the stack
faster?  (And being register-rich is one of the arguments people make for
RISC architecture!  Gimme a good hardware based LRU register buffering scheme,
and then maybe we'll talk...:) }


>Anybody understand the following?
>
>NO IFBMS      NO AMIFGAS       NO MFACS       NO WFAY

Multitasking is the best thfing since sliced bread! :)

			Antony


*******************************************************************************
Antony A. Courtney				antony@lbl.gov
Advanced Development Group			ucbvax!lbl-csam.arpa!antony
Lawrence Berkeley Laboratory			AACourtney@lbl.gov