Re: RFC: Prototype for a user threading library in Ada

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

"Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message 
news:f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com...
...
>> I'd like to understand better the motivations for these features, so if 
>> you
>> (or anyone else) wants to try to explain them to me, feel free. (But keep 
>> in
>> mind that I tend to be hard to convince of anything these days, so don't
>> bother if you're going to give up easily. ;-)
>
>See above. Being able to easily write highly concurrent code is of limited 
>use
>if said code ends up running with terrible performance because modern OSs
>are not at all optimized for this kind of workload. We shouldn't need to
>worry about how our users' OS kernels are setup, and user threading and
>coroutines are a solution to this problem.

Only if you want to make the user work even harder than ever.

It seems to me that the problem is with the "typical" Ada implementation 
more than with the expressiveness of features, when it comes to highly 
parallel implementations. Mapping tasks directly to OS threads only works if 
the number of tasks is small. So if it hurts when you do that, then DON'T DO 
THAT!! :-)

There's no reason for any particular mapping of Ada tasks to OS threads. I 
agree with you that the best plan is most likely having a number of threads 
roughly the same as the number of cores (although that could vary for a 
highly I/O intensive task). Ada already exposes ways to map tasks to cores, 
and that clearly could be extended slightly to manage the tasking system's 
mapping of threads to tasks.

I use Ada because I want it to prevent or detect all of my programming 
mistakes before I have to debug something. (I HATE debugging!). I'd like to 
extend that to parallel programming to the extent possible. I don't want to 
be adding major new features that will make that harder.

                                            Randy.