Re: GNAT and Tasklets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 18 Dec 2014 11:34:18 +0200, Niklas Holsti wrote:

> 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.

My concern is OS limitations and the overhead for the scheduler caused by
merely having a thread. A co-routine will never appear in the list of
active tasks.

> 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.

Maybe, but in earlier days, same was said about processes. Why should
anybody introduce threads? Still threads are lighter than processes and
become lighter in relation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de