ARGON

[Sean 'Captain Napalm' Conner]

On some network somewhere in cyberspace, Alaric B. Williams transmitted:
> 
> >   Strange, or coincidental.  Fare and I have gone head to head several times
> > over cooperative vs. preemptive multitasking (check both the tunes and the
> > tunes-lll mailing list archive).  I don't see how cooperative multitasking,
> > in a general purpose system, can be faster than a preemptive multitasking
> > system.
> 
> The emphasis is on can be :-)
> 
> I'll let you into a little secret: I just can't bare writing 
> interrupt handlers...
>  
  At some point, an interrupt handler will have to be written.  Not by you,
but someone, unless you really don't mind dropping characters from the
serial port because you can't poll fast enough (you might be able to get
away with 300 baud, maybe 1200.  At 2400 or faster, you'll either have to
have an exceedingly fast CPU, or multiple CPUs, one to handle the serial
port exclusively, the other to do other general stuff.  I'll get to that
point in a second).

> >   True, a cooperative system can save less "state" than a preemptive system,
> > but in all the preemptive systems I've seen, the only "state" that's been
> > preserved have been registers.  And on those systems with virtual memory,
> > it's always been another "register" that needs to be saved to save the
> > memory space of the process.
> 
> I've always been attracted by the potential for reliability. 

  Well, Windows is cooperative, <sarcasm> and it's well known for its
reliablilty </sarcasm>.

> Interrupts create temporal complexity, without which I can be much 
> surer what my software's doing, without such overkill use of locks 
> and so on.
> 
  Once you starting having multiple CPUs (which is somethiing Fare is
talking about) you start having problems with mutual exclusion and so on. 
Sure, in a single CPU system, you can avoid those messy locks by just
holding onto the CPU for the critical section (and most code for the Amiga
does just that, calls Forbid() (stops multitasking) and Permit() (reenables
multitasking) or even Disable() (stops interrupts) and Enable() (reenables
interrupts). 

  The problem with that method is on a multiple CPU system, Forbid() may
prevent any new tasks from starting, but it does nothing to stop a task
running on another CPU.  It COULD, but then you have two more problems:

	1. it's no longer cooperative (unless you wait for the other process
	   to call yeild()).

	2. you loose performance (in any case) because the second CPU is
	   then not doing anything useful.

  There may be ways around that with clever programming to see of the task
on the second CPU may be executing the same code as the first CPU, but that
sounds just as ugly (if not more so) than dealing with locking issues up
front.

  Note that this is a multiple CPU problem, not a cooperative vs. preemptive
issue.

  -spc (If your only experience with interrupt handlers are from MS-DOS
	or Unix, then I can see why you find them complex ... )