Multithreading (was: Writing an OS for PC)

[Francois-Rene Rideau]

>>[talking about how cooperative multitasking is more efficient,
>> but requires more security than existing OSes and development tools
>> can provide]

>    Don't you how boring it is to reorganize your code just to do:
>    for i:=0 to 100
>        let_the_others_work();
>    end
>    This is even more true in OO applications !
>
>    Do you imagine yourself saying during the development of Tunes:
>    "Well, the files managing team have finished their work, so the video
>     managing team can start..."
>
>    NONSENSE !

   You seem to believe that because code must yield() execution,
it should explicitly schedule, which is false: programs just need yield(),
and with proper binding, this causes the system to schedule a new thread if
the current thread did time-out.
   Actually, high-level programs using a high-level TUNES compiler need not
even explicitly yield() execution either: the compiler can very well do it
automatically; the programmer could still show the compiler how to optimize
things.
   Basically, there must be a yield() often enough so that non-real-time
threads are run with sufficiently good resolution. That is, the (computer
or human) compiler must track how long each block takes to execute, and
be sure that for every long enough block, there is a yield() inside.
Loops are easy to manage: either the inside code is large enough, and will
have had a yield() inserted, or the loop will have to be split into smaller
loops each having a yield() at the end (which can be done at run-time or
compile time). The trickiest is recursivity, where you must insert a yield()
at every function call (but still, you could unroll the function's definition).
And you're not even required to yield if you know the execution will be
quicker than the required resolution...
   Now the cost of a yield() is not very high: until the timer or some
event decides that a new thread must be scheduled, yield() calls a function
that returns immediately. On a i486 PC, this is some twelve cycles, not more,
and to have the same user-level resolution as a 100 Hz timer, you are
required to insert them only every 10000 or 100000 cycles...
   Of course that may be more costly on a 16MHz 386sx computer, but still,
it's much more efficient than preemptive multitasking.


>    Cooperation between objects is important of course...
>    But it must be cooperation, in terms of communication, between parallel
>    tasks supervised (Is it english ? ;-) by the teams' manager (the OS...) !
  Uh ? "Cooperative" multitasking actually just means that programs abide
by some rule about yielding execution. Programs need not know what happens
when they yield, but that they will be given execution back some time later.
I don't think there is any direct relation between "cooperative" multit*ing
and the kind of cooperation you are just talking about (I may be confused,
however).


>    If you choose cooperation multitasking then Tunes is already dead !
>    Or proove me the way you are going to implement such a concept in Tunes
>    applications.
>    I mean in an efficient way ! That will not suck as you say ! ;-)
   Well, I still have to see any argument why cooperative multithreading
is impossible, unefficient, or not desirable. Sure it is impossible
*using existing Oses and Language tools*. But as TUNES is redesigning an OS
from scratch, it can do it.


--    ,        	                                ,           _ 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://acacia.ens.fr:8080/home/rideau/Tunes/"