Re: GNAT and Tasklets

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

On Thu, 18 Dec 2014 00:56:30 -0800 (PST), vincent.diemunsch@gmail.com
wrote:

> Le jeudi 18 décembre 2014 09:41:53 UTC+1, Dmitry A. Kazakov a écrit :
>> 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.
>> 
> What is a "physical task" and a "logical task" ?
> For me :
> - a task is a "logical task", because it is a concept of the Ada langage.
> - a thread is what you call a "physical task", because it is an OS feature.

RM mingles task and thread:

"The execution of an Ada program consists of the execution of one or more
tasks. Each task represents a separate thread of control that proceeds
independently and concurrently between the points where it interacts with
other tasks." RM 9(1)

Your "thread" is an implementation of a task.

> And if there should be a clear rule inside the Ada langage I would argue for
> a simple rule like :
>  - tasks (and task types) declared at Library level are mapped to kernel threads

Why? One is about visibility, scope, elaboration another is about
scheduling. Scheduling by OS is IMO not related to the scope.

>  - tasks (and task types) declared localy are mapped to simple jobs spawned to a
>    pool of tasks.
> 
> And add the use of pragma, or aspects, for special cases (GPU...)

I don't think pragma would be enough. It is all about scheduling. Physical
tasks are scheduled by timer interrupts or other steady event sources,
which makes task interactions, such as rendezvous, more or less reliable. 

The case of co-routines scheduling is different because the driving events
(new data are here, GUI event signaled, HTTP multipart chunk received) are
no more *independent*.

If scheduling is not independent then tasks are not. Note, the RM's
definition, which mentions independence. It is not only things like
task-owned objects and state. It is also the concept that a task can be
preempted without behavior change. This is less true for co-routines which
are less "task" in this sense.

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