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

[Hadrien Grasland <hadrien.grasland@gmail.com>]

Le dimanche 26 juin 2016 05:09:25 UTC+2, Randy Brukardt a écrit :
> "Hadrien Grasland" wrote in message...
> ...
> >> 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.

Not necessarily so, good higher-level abstractions can help here. However, I definitely agree with your following point:


> 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!! :-)

Yes, the problem could be solved at the Ada implementation level. That would also help greatly with the abstraction side of things, as "natural" Ada abstractions could be made to work as expected (see below).

However, any code which relies on this implementation characteristic would then become unportable, unless the standard also imposes that all implementation follow this path. Would that really be a reasonable request to make?


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

An Ada implementation which would want to make the life of concurrent programmers easier could do the following things:

1/ Keep the amount of OS threads low (about the amount of CPU cores, a bit more for I/O), and map tasks to threads in an 1:N fashion.
2/ Make sure that any Ada feature which blocks tasks does the right thing by switching to another task and taking care of waking up the blocked task later, instead of just blocking the underlying OS thread.
3/ Make sure that the Ada standard library implementation behaves in a similarly sensible way, by replacing blocking system calls with nonblocking alternatives.

That is essentially what the Go programming language designers designed their tasking model, so it is possible to do it in a newly created programming language/implementation. But how hard would it be to retrofit it inside an existing Ada implementation? This I could not tell.