Pre-emptive vs. Cooperative Multitasking

[Francois-Rene Rideau]

">>>>" is Jecel,
">>>" is Billy.
">>" is me (Fare)
">" is Billy again

>>>>   - 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.
   Because the function is not actually called ! Instead, code is modified at
some point by the interrupt-driven routine that decides of a schedule...


> 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.
   Yep. I ask no more when I say "cooperation".


>>    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).
   We do not disagree. Only as I see things, there is no reason why the
object and the meta-object should communicate between each other through
a static "black-box" mechanism, while on the contrary, having data from
the context being spread in the implementation of the object leads to
increased performance.


> 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.
   That's one way to do scheduling that I appreciate indeed.


>>    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.
   I think we agree. Our divergences were in point of view, not in opinion.


> -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.
   I fear that TUNES is a motto in itself. However, the LLL subproject does
not have a motto, and yours suits it very well; would you mind if this becomes
the motto for the LLL subproject instead ?

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"