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

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

Le samedi 2 juillet 2016 23:14:30 UTC+2, Niklas Holsti a écrit :
> On 16-07-02 14:13 , Hadrien Grasland wrote:
> > Le samedi 2 juillet 2016 06:36:09 UTC+2, Randy Brukardt a écrit :
> >> But I don't think that really helps the race and deadlock issues
> >> that are the real problem with programming with Ada tasks. I'd like
> >> to find some help there, too.
> >
> > Here's my view of this: people are heavily overusing shared mutable
> > data in multitasking programs, and that is the source of too many
> > data races, which in turn people attempt to fix with locks, thusly
> > killing their performance and introducing deadlocks.
> >
> > In many cases, better performance and correctness can be easily
> > achieved by moving to asynchronous tasking runtimes, where the
> > runtime internally manages an event-based dependency graph of tasks
> > that can be processed condurrently, and data is kept task-private but
> > can be moved around between tasks.
> 
> Do you have real experience of such "asynchronous tasking runtimes"? In 
> Ada or in other languages?

I have quite a bit of experience with OpenCL and HPX. OpenCL is based on raw events, while HPX adds some nice syntaxic sugar for moving data across tasks in the form of futures.

OpenCL is an API that was designed for offloading parallel computations to pretty much every kind of programmable hardware, so its designers had to pay quite a bit of attention to IO latency concerns when designing it, which naturally led them to embrace an asynchronous tasking model. Whereas if you are familiar with the C++11 std::async construct, HPX is essentially that programming model on steroids (more limited in hardware scope than OpenCL, but more pleasant to use).

As for languages, OpenCL is a C API, though I ended up writing a C++ wrapper fairly quickly because the C constructs were hurting my eyes too much. HPX is a C++ API. I am not aware of any similar similar work in Ada, so since I really like this programming model, I thought I would give it a shot.


> It seems to me that it would be difficult for such a run-time system to 
> support the full Ada tasking features, such as conditional entry calls. 
> Ada tasks have more control over their own execution than such a 
> run-time system would allow.

Yes, to support the full Ada tasking feature set would likely entail getting support from compiler implementors, see the lengthy discussion on coroutines above for an example :)

 
> Moreover, in present Ada it seems to me that the only way to move 
> task-private data from one task to another is to send a copy of the data 
> from one task to the other. Copying data is often poison for performance.

Cheaply moving data around is possible in any language that has heap allocation and pointers. What is more difficult is to provide an easy to use syntax around it.


> Perhaps a new, restricted tasking profile would be needed, analogous to 
> the Ravenscar profile but aimed not at real-time systems but at parallel 
> computation in this event-based style.

It is true that for computation purposes, the full Ada tasking model may also be overkill. For example, asynchronous transfer of control can be hard to support, and is often overkill for compute scenarios.