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

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

Le vendredi 17 juin 2016 18:18:25 UTC+2, Niklas Holsti a écrit :
> I had a quick first look, and it seems interesting, but I have two 
> suggestions to make the development more understandable to the 
> Ada-oriented reader:
> 
> - First, please do not redefine the word "task", even in the qualified 
> form "asynchronous task". It is quite confusing, in the Ada context.
> 
> - 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.

Terminology has indeed been much of a pain for me, and something I can improve before freezing the interface. The main issue that I have is to find a good usability compromise between reusing familiar names when possible, and avoiding name clashes with existing concepts that have different meanings.

I thought I could be fine by focusing on terms that are known to have highly overloaded meanings across the software landscape, and thus warn the user that special attention to definitions is required, but you are right that in the Ada context "task" is definitely problematic enough to warrant trying to find something else.

What's nice about "task", in a C++ context at least, is that the Intel marketing department did quite a good job of imposing that as the official terminology for the elementary work unit of user-mode cooperative multitasking facilities. They were followed in this by other "task-parallel" libraries like HPX, so these days, when someone familiar with one of these libraries sees a "task", they get an idea which is quite close to what I mean here.

Common alternatives such as "green threads" or "user thread" are clearly inferior, in the sense of being politically loaded in the first case and only comprehensible by people with an OS tech background in the second case. "coroutine" or "process" is abusing established terminology that means something very different, and "generator" is only really usable for functional abstractions that yield results, as it is a very clumsy term to describe procedural abstractions that simply return control to the caller.

As for "work-item", it is something which I played with recently, but I'm not very keen on it either because in the OpenCL context, it has a totally different meaning, and I thus fear that users experienced with the OpenCL terminology would interprete a "work-item" as something that is somewhat lightweight, and fall in the trap of too fine a task granularity. Still, it looks better than the options above, so I may converge on it unless a better idea emerges.

Again, the great thing about "task" is that it is highly descriptive and was not widely used in the C++ community before, but obviously that is not true in an Ada context.

---

On the other hand, I am quite keen on "event" because what I am proposing is a near-superset of the OpenCL event model, although the use of a higher-level programming language allows for a much more convenient programming interface. An alternative which I had in mind was "completion", but although it brings some disambiguation with the interrupt-like event model used by e.g. GUI toolkits, it is also highly nonstandard, and somewhat confusing in the sense that "manipulating a completion" is meaningless.