Pre-emptive vs. Cooperative Multitasking

[Billy Tanksley]

On Fri, 21 Jul 1995, Francois-Rene Rideau wrote:

> ">>" is Jecel,
> ">" is Billy.

Add a layer of inderection to that, of course.

> >>   - Cooperative Multitasking: Mostly avoids the need to explicitly
> >>     control resource sharing. Allows you to violate "invariants"
> >>     to boost performance as long as things are restored to normal
> >>     before the next task switching point.

> > Note that all that good stuff is destroyed by the fact that you must poll 
> > for tasks at all other times.
>    Polling costs almost nothing as compared to the heavy cost of complete
> state saving. Saving the complete state costs thousands of cycles. If well
> implemented, polling costs some ten cycles each time. If even better
> implemented, it costs nothing at all (see URL above).

I'll have to take a look-- it doesn't make any sense how calling any 
function could not take time.

I do agree that state saving is too expensive-- the best multithreader I 
know of is probably so fast simply because it runs on 8*86es, with not 
much state to save.  Nonetheless, it does use some cooperative 
state-saving techniques-- but no cooperative multitasking.

> > Essentially, the only advantage I can see for cooperative MT is during 
> > short critical loops, and why not just explicitly give those loops 
> > control?

>    Cooperation is just *required* for persistency, inter-thread and
> distributed GC (remember, TUNES is to provide all that, too). Of course,
> you could use "conservative" GC and persistency, but that sures costs much
> more than cooperative schemes. By writing cooperative code, you pay once and
> for all when you write the compiler; by promoting anarchy, you must be
> paranoid, and you never cease to pay the cost.

I think we're operating on mixed wavelengths, possibly.  I'm not an 
anarchist, in code or otherwise; I simply see tasking as the domain of 
the superobject (known by some OSes as the kernel).

In fact, one possible scheme that I think would fit with TUNES is to have 
each object depend upon its superior for computing time.  That way you 
don't need a huge central authority-- only big enough to apportion power 
among the topmost objects.  You could have some object types that 
delivered power preemptively, others that depended upon cooperation 
exclusively.

>    Cooperation is to follow laws, to increase information. It does *not*
> oppose preemption. It opposes absence of cooperation, which is anarchy.

I support preemption.  I do not oppose cooperation.

-Billy
Does TUNES have a motto?  (Or was that it in your .sig that I just 
deleted?)  If not, may I suggest "rem non spem, factum non dictum", 
meaning (in its original context) "an action, not hope; facts not speech", 
but better translated here as "an object rather than a procedure, a fact 
rather than a word".

The first part will serve to show others what the OS is-- a fully OO 
system.  The second will keep reminding us what to do about it.  Sorry, I 
forget the source for this quote, but I'll look it up if you feel you can 
use it.