Re: GNAT�and Tasklets

[vincent.diemunsch@gmail.com]

Hello Randy,

Thank you for your response. I find it a little bit confusing in fact.

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

Have you heard of Ravenscar ? The idea is to restrict tasking to a simple subset
that is both predictable, therefore easy to set up right, and light to implement.
I am pretty sure, that local tasks could be restricted a lot and yet be very useful.
And tasks with very limited synchronization, without rendez-vous, are easy to
manage.

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

So what ? We will continue to make it more and more complex ? Isn't it possible
to stop that trend and try to do better ?
 
> Besides, you confuse the appearance of simple (that is simple to use, simple 
> to learn) with simple in language terms.

When I say "simple", I simply means "simple in langage terms". For me a compiler
is a tool that allows us to generate machine code, without the difficulty of using
assembly langage. That's why it brings simplicity. And I know well that a compiler
is complex : parsing, AST expansion, type evaluation, code generation, all this 
requires a lot of theatrical work. I only have the feeling that compilers are still
lacking theoretical grounding upon tasking, and therefore are not able to deal
with it in a useful way.

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

We agree on that point :-).

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

That's funny ! Really are you serious ? Ada have created the task abstraction
to deal with parallelism, and for me it is an abstraction, that can be implemented
by different ways, depending on the compiler, the OS but also the way it is used 
inside the program. First you are telling me that it is too difficult for a compiler to
implement this abstraction in an other way than a heavy OS thread, because it 
would be to complex to automatically find simple cases allowing reduce tasking,
and because a runtime library using mixed tasking would be to difficult to write.
And strongly disagree to both arguments : 
1. the Ravenscar profile is a counter example, and using aspects or pragma should 
allow us to make useful restrictions on local tasks
2. the Paraffin library shows clearly that we can have mixed tasking, for it can be
used in parallel to tasks. 
And after, that you pretend seriously that a compiler should be able to find by its 
own parallelism in the program ! It seems to me a major contradiction !

No, creating a parallel program is far more complex than creating a sequential
one, and until we have a compiler so smart to do this, I prefer to rely on
explicit tasking.
 
> 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).

See Linear Temporal Logic and Model Checking based on that logic. It is
the foundation of concurrency. But to make parallel computation, we really
don't need such complexity.

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

Fine.

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

That is why I am taking time to discuss on this forum.

> You should have noted by now that pretty much everyone who has answered 
> here has disagreed with your position. 

No I haven't noticed. I had the feeling that at least Dimitry and Brad had were
sensible to some of my points. But even if it was the case, that doesn't mean that 
I went wrong :-) Montesquieu said "The less you think, the more people agree with you" :-).

Kind regards,

Vincent