Re: GNAT and Tasklets

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

<vincent.diemunsch@gmail.com> wrote in message 
news:9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com...
...
>And if the compiler chose only one implementation, like always a kernel 
>thread
>for a task, which is the case now, I have to say that it is not a mature
>implementation of tasking.

In which case I think you will have an approximately 0% chance of ever 
encountering your idea of a "mature implementation of tasking" in an Ada 
compiler. Ada tasking is far too complex to implement it more than once, 
especially with all of the potential race conditions and deadlocks that 
mixed implementations would face.

There is no such thing as a "lightweight Ada task". The syntax is heavy, the 
semantics is heavy (separate stack, exception handling, finalization, 
termination), and as a correlary, the implementation is heavy.

>Finaly, I really hope that the new version of the langage will keep Ada 
>simple ...

That ship sailed with Ada 95, if it ever was true at all.

Besides, you confuse the appearance of simple (that is simple to use, simple 
to learn) with simple in language terms.

    My_Vector(I) := 10;

looks simple, but if My_Vector is a vector container, what actually happens 
is anything but simple. But so what? Only people that have to write/debug 
containers ought to care; we've made usage simple at the cost of making 
creation harder.

Similarly,
    for I in parallel 1 .. 10 loop
       ...
    end loop;

looks and feels simple, even though what would have to happen under the 
covers to implement that is anything but simple.

>and add "intelligence" in compilers and not add different new features with 
>:
>- tasks for kernel threads
>- coroutines or tasklets for user-level threads
>- jobs for lightweight threads,
>because this would be a major conceptual regression. I believe that aspects
>on tasks could be an inelegant but decent way to solve the problem.

You are still thinking way too low-level. Creating a parallel program should 
be as easy as creating a sequential one. There should (almost) be no special 
constructs at all. Ideally, most programs would be made up of parallel loops 
and blocks, and there would be hardly any tasks (mainly to be used for 
separate conceptual things).

Writing a task correctly is a nearly impossible job, especially as it isn't 
possible to statically eliminate deadlocks and race conditions. It's not 
something for the "normal" programmer to do. We surely don't want to put 
Ada's future in that box -- it would eventually have no future (especially 
if very-many-core machines become as common as some predict).

In any case, there won't be any major upgrade of the Ada language for at 
least another 5 years. The upcoming Corrigendum (bug fix) has few new 
features and those are all tied to specific bugs in the Ada 2012. So I 
wouldn't wait for language changes to bail you out; Brad's libraries are the 
best option for now.

Also please note that language enhancements occur through a process of 
consensus. Most of the ARG has to agree on a direction before it gets into 
the language standard. You should have noted by now that pretty much 
everyone who has answered here has disagreed with your position. It's highly 
unlikely that the ARG would invent language changes that the majority of the 
Ada community think are the wrong direction. That's especially true as Brad 
and I are on the ARG and are working on these language changes. The ARG has 
already voted to continue work in the direction that the "Group of Four" 
proposed (which is similar to what I would propose if it was up to me). I'd 
be very surprised if we made a u-turn at this point (especially as the 
proposals fit well into the existing framework of Ada and most are useful 
outside of the narrow area of parallel operations). This will be a big job 
and it will be a long time before we get to the real nitty-gritty of these 
proposals (the problems will be in the details, not the broad outline --  
anyone can do that!). Anyway, you can swim against the current if you like, 
but you most likely aren't going to get anywhere doing that.

                                        Randy.