Pre-emptive vs. Cooperative Multitasking

[Francois-Rene Rideau]

>>> 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 would call that preemptive.  However, it's a very clever preemption,
> achieving almost all the benifits with almost none of the losses.  I
> think it highlights the fact that we are in agreement.
   I'm happy to read that :-)


> (When I first saw that phrase "code is modified" I nearly choked-- after
> all, I've been trained to never (seldom) write self-modifing code.
   The problems with self-modifying code are two: firstly, traditional
languages give it very complex semantics when it is possible, so people
are discouraged to use it, because they will most probably do it wrong, and
it will be a pain to maintain. However, the TUNES languages strives to allow
any conforming implementation to a specified object. Using self-modifying
code in a controlled environment can be secure, and with very well-known
and simple semantics, if done through proper tools. The second problem is
that harvard architecture with separate instruction and data memory or cache
make it difficult or inefficient; a more traditional polling will have to be
used on such architectures...


> It's a
> good thing I taught myself a few bad habits before the teachers got to me,
> or I probably wouldn't have recognised that that's precisely what we're 
> developing our language as!)
   If you mean that in implementing the system, we'll allow ourselves to use
all the possible hacks that exist, yes, because we'll build tools that will
make these hacks secure, when they currently are unsecure and difficult to
maintain or even use on existing development platforms.


>>    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.
> Our only disagreement was in words.  I accept your nomenclature as being 
> superior and more useful for this project.
   I'm glad to read we agree, too. Of course I think good of my nomenclature,
but I'm open to any suggestion to improve it. Anyway, the important is that
even if we can fight for definitions, we know precisely what each other means.


>>> 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.
> Here's an elaboration: how about if all power, both computing and 
> otherwise, is passed down a hierarchy of objects?  In order to recive 
> computing time an object must be attached to a power-providing object 
> (perhaps the clock, perhaps some other object attached to the clock), and 
> in order to be visible an object must be attached to a vision-providing 
> object.
   Yes, that's exactly how I think things should be implemented.
   However, at high-level, I also want migration to be possible and easy
from some providing object to another, so this will constrain implementation
in some way.


> Some computational objects would be miserly, granting power only to 
> relinquish it quickly (the essence of preemptiveness), while others would 
> simply give power to the next object on their list and take it back only 
> when asked to.


>>    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 ?
>
> I'd be honored-- and I can't help but chuckle at the appropriateness.  I
> wish I'd thought of it.  Ok, I just searched my books for the source of
> that, but I can't find the derivation.  It's either original to the
> authors of the book or they've violated some long-dead Roman's copyright. 
> Hmm, I wonder which?
>
> The full quote (which wouldn't work as a motto) is "Rem non spem, factum 
> non dictum, quaerit amicus."  The book translates it as "A friend seeks 
> support, not promises; action, not talk."  The book, by the way, is Artes 
> Latinae, level 1, book 1, by Waldo E. Sweet (Encyclopedia Brittanica).
   Err, why wouldn't it work as a motto ? Currently, I've just added it to
the LLL page; tell me if I'm doing wrong...

--    ,        	                                ,           _ 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/"