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

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

Le dimanche 3 juillet 2016 10:39:48 UTC+2, Dmitry A. Kazakov a écrit :
> On 2016-07-03 09:42, Hadrien Grasland wrote:
> > Le samedi 2 juillet 2016 23:14:30 UTC+2, Niklas Holsti a écrit :
> 
> >> 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.
> 
> That is the most expensive way doing it, and on top of that, it requires 
> shared memory (pool) and thus process-global interlocking. You arrived 
> at the starting point.

Please define what you mean by expensive. Whenever the hardware architecture allows for it, passing a pointer to a heap-allocated data block is almost always faster than deep-copying that data from one thread-private area of memory to another, as long as the data is large enough.

 
> BTW, when talking about asynchronous model, marshaling must be 
> asynchronous too. Another drawback of the method of doing that through 
> pointers is that it must be atomic = synchronous => you could not deal 
> with large objects, on-demand production models etc. And this is where 
> event-controlled model stop working, as it separates data from 
> data-related events. A proper abstraction must combine everything into 
> ADT objects.

Indeed, I also agree that when an event is used to notify a listener that some piece of data has been produced, it is almost always better to combine together the event and the data block being produced in a single abstraction, a future.

However, futures are less general than events. In runtimes that only have futures, like HPX, you cannot easily express the completion of procedural operations. You just end up with horrible hacks such as hpx::future<void> ("a future of nothing"). This is why I believe that events are best as a low-level layer, on top of which higher-level abstractions such as futures can be built.


> > What is more difficult is to provide an easy to
> > use syntax around it.
> 
> Hmm, what is difficult about procedure call?

Basically, it is best if producers and consumers do not actually manipulate raw pointers to the heap-allocated blocks.

Otherwise, there is always a risk of a producer retaining access to the produced block and later manipulating it in a racey fashion.

A better option is to have a system where at the point where a producer "emits" data, it loses access to the associated data block. Of course, this is impossible to achieve in a perfectly fool-proof way, but we can make it harder for developers to shoot themselves in the foot, using things like futures.