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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 03/07/2016 23:15, Hadrien Grasland wrote:
> 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.

Any operation that blocks all CPUs.

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

This might be true only for architectures of few cores and shared 
memory. A massively parallel or distributed system cannot be built this way.

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

The idea is make it looking like normal tasks and protected objects 
doing normal blocking operations on normal objects without exposing 
implementation details like events. We could still have events 
implemented through  protected objects.

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

In Ada parameter passing is up to the implementation (with some 
exceptions). So if by-reference is the most efficient method of 
parameter passing the compiler will choose it. That is why I see no 
problem with the syntax.

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

OK, the aliasing problem is always a problem.

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

One method is passing a controlled handle to the shared 
reference-counted object. The handle is invalidated upon return to the 
producer so that it will not be able to access the target object after that.

Another method is reference-counted "transactional" objects. A mutator 
operation on the object looks at the reference count, if it is greater 
than 1, it copies the object, uses the copy, sets the handle to point to 
the copy upon return.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de