ARGON (fwd)

[Sean 'Captain Napalm' Conner]

  He sent this to me privately, but I have his permission to post this to
the list.

On some network somewhere in cyberspace, Joseph E. Van Riper III transmitted:
> Mr. Conner wrote:
> >On some network somewhere in cyberspace, Alaric B. Williams transmitted:
> >
> >> >   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>.
> 
> My understanding is that Windows 95 is pre-emptive, although Windows is
> co-operative.  The Mac's OS (Finder) is also co-operative.  In fact, in
> every example of a co-operative operating system (even ones that are
> relatively stable), pre-emptive always seemed to work better.
> 
> >> 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.
> 
> Brew ha ha ha ha!  Another Amiga user!
> 
> Perhaps the approach to this problem can be found in a kind of
> Forbid/Permit message to the particular object to be locked.  After all,
> what we're looking for is a way to keep objects from being tampered with
> while we're busy messing around with it, yet we don't want to lock up the
> processor in the process (puns intended).  If the memory management
> routines automatically test whatever object is to be moved about in memory
> for whether or not the object is locked, this could stabilize it.  The
> locking mechanism could be designed in such a way that it requires a kind
> of 'password' that only the object invoking the lock may have (initially).
> This way, other objects *could* 'unlock' the object if the original locking
> object needs to pass control somewhere else (thus, no objects become
> permanently locked).
> 
> - Trey (who cant remember the name of the list, so is posting to you privately).
> 
>