Re: GNAT and Tasklets

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-12-18 10:42 , Dmitry A. Kazakov wrote:
> On Wed, 17 Dec 2014 22:31:57 +0200, Niklas Holsti wrote:
>
>> As Brad said, another purpose is to separate logical threads
>> of control, and I would add a third purpose, which is to prioritize
>> tasks of different urgencies, for real-time systems.
>
> This is a very important point.
>
> In my branch of work (data/event driven architectures) a great deal of
> things could be designed much easily and safely if state machines were
> replaced by a logical chain of control ("task"). It would not mean a
> separate physical task behind. Actually in most cases it is just few
> physical tasks and thousands of logical tasks scheduled by events.
>
> If Ada supported this (co-routines) it would greatly simplify I/O, GUI, Web
> designs.

The problem is that implementing a co-routine is not much easier/lighter 
than implementing a task, *if* you let the co-routine use subprograms 
and let it "yield" (that is, pass control to some other co-routine) 
inside a nest of subprogram calls.

If you only allow "yield" at the outermost or "main" subprogram of a 
co-routine, you can make the co-routines share the same stack and the 
same "physical task". Of course you must still arrange for separate 
storage of the local variables of the main subprogram of each 
co-routine, but that is not too hard.

But if "yield" can occur at any depth in a nest of subprogram calls, 
then each co-routine must have its own stack. Perhaps the overhead of 
co-routine switching could still be less than for task switching, 
because co-routine switching would not be pre-emptive, but IMO that is 
an unimportant optimisation.

So it seems to me that there is a fundamental conflict between the idea 
of light-weight co-routines on the one hand, and the use of procedural 
abstraction of behaviour, on the other hand.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .