Re: GNAT and Tasklets

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

<vincent.diemunsch@gmail.com> wrote in message 
news:0b33cce3-7b1b-47e0-9d6d-48fafcfb025c@googlegroups.com...
>Le mercredi 17 décembre 2014 22:08:33 UTC+1, Brad Moore a écrit :

>>> I could understand that a Library level task (i.e. a task declared 
>>> immediately
>>> in a package that is at lirary level) be mapped to an OS thread, but a
>>> simple local task should definetly not.
>>
>> Why not?
>
>Because a thread is, in my understanding of an OS, an abstraction of a CPU. 
>And
>technicaly a kernel thread is a scarce ressource, because it needs to store 
>data
>inside the kernel, with a strong overhead because creating it, destroying 
>it and
>even using it is done through expensive kernel - process transitions.

Which matches almost exactly the language requirements of an Ada task. These 
are fairly heavyweight structures, requiring their own separate stacks, 
exception management, finalization management, termination management, etc. 
Initializing and destroying these things is not trivial.

>A local task is a simple way to express parallelism in a part of an 
>alogrithm inside a
>subrogram.

Maybe for you, but not in Ada.

>It must be lightweight otherwise it is useless.

Surely not; there are plenty of uses that do not involve explicitly creating 
parallelism. "Lightweight Ada task" is an oxymoron. On top of which, the 
compiler should be creating and managing lightweight parallelism, not the 
programmer (the compiler/runtime know a lot more about the execution 
environment than the programmer can or should). If you have to write much 
beyond a keyword, we've already failed.

>And it is exactly the problem we encountered, for current compiler creates
>heavy kernel threads even for little tasks.

There are no "little tasks" in Ada. You want something else, which Ada 
doesn't have at the moment.

> Remember it was also my motivation
>at the beginning of this post : to have a Library to do parallelism.
> So I have a good response now, for I think you have very well
>solved the problem with your Library, that I will try to use !

>But it remains the question of the Ada language : it is not acceptable that
>Ada degenerates slowly into a low level langage, where we need to
>replace a task abstraction by
>- a procedure
>- an access to that procedure
>- the instanciation of a spawning mecanism, taking the access to 
>subprogramm.
>This is exactly the job of a compiler !

Yes, of course. The reason Brad built his library was to get experience into 
what could reasonably be done and not done with the language as it stands. 
And now he and others are working on language proposals for the future for 
parallel loops and blocks among other things in order to make these things a 
first-class part of the language.

But language change is a long and slow process, in part because we have to 
get it right the first time. 'cause we're stuck with whatever we come up 
with forever (note the other discussion on anonymous access types).

                                     Randy.