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

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

Le vendredi 17 juin 2016 18:46:46 UTC+2, Dmitry A. Kazakov a écrit :
> On 2016-06-17 18:18, Niklas Holsti wrote:
> 
> > - First, please do not redefine the word "task", even in the qualified
> > form "asynchronous task". It is quite confusing, in the Ada context.
> 
> Yes.
> 
> > - Second, I question the terminology of "user thread". The "events", or
> > "asynchronous tasks", are not "threads" in the sense of keeping their
> > own machine-level control-flow state; they are automata that are invoked
> > from the "executors" through a single "Run" operation. If some
> > control-flow state must be kept between invocations of "Run", the
> > "asynchronous task" must keep it in Ada-level variables/components.
> >
> > I don't quite know what to call your "events" / "asynchronous tasks",
> > but perhaps the term "work item", which you use in a comment, is better.
> 
> "Event" looks like a plain event (as opposed to a pulse event). 
> "Asynchronous task" looks like a subprogram, not a task proper, not even 
> a co-routine.
> 
> My take on this problematic is that there cannot exist a solution 
> implemented at the library level. All these frameworks maybe fun (for 
> the developer) but useless (horror for the end user) when the key 
> problem is not solved. That is, the control-flow state (as you said) and 
> the stack of the local objects both preserved between scheduling points. 
> This can be done IMO only at the language level as co-routines, 
> non-preemptive, cooperative, user-scheduled tasks, call it as you wish.

I agree that implementation support for coroutines would be extremely valuable, if it were available at the language level (as in Python, C#, Go...) or even in specific implementations (as in Visual C++).

In addition to the benefits you mention, I will also add that a language-level implementation can potentially trap blocking system calls and substitute them with task switches for latency hiding. It will also get wide support from the standard library instead of requiring many custom primitives an wrapper, which means more development time to focus on the core concurrency model.

However, I think that as it stands, we are just about as likely to see it happening in Ada as we are to get lambdas and first-class function objects. So at some point, it is necessary to move on, and try to do what we can at the library level. In my case, state saving is partially available in the sense that any data member of Asynchronous_Task is preserved across iterations, so we do get something relatively straightforward to use, but I will certainly agree that this something is less flexible and pleasant to use than full language-level coroutine/generator support.

If this prototype works well, there is hope to take it further in the long term, though. For example, the productive interaction of HPX with the C++17 commitee has shown that having a working (even if clumsy) implementation of new concurrent primitives is a very strong argument when interacting with a language standardization commitee in order to request new language features that make these primitives easier to implement and use.

And even if we really cannot get the language features, if I get this project far enough to motivate other developers to join, it is also possible to envision implementing architecture- and OS-specific automatic task state saving, as in Intel TBB, which is something which I will refuse to do for now because it is too difficult to handle for a lone developer with a limited base of test hardware.