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

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

Le samedi 2 juillet 2016 15:18:58 UTC+2, Dmitry A. Kazakov a écrit :
> On 2016-07-02 13: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,
> 
> This is motivated by the hardware architecture of multi-cores with 
> shared memory.

Fair enough, but I would argue that outside of the realm of data-parallel algorithms, most of the benefits of shared memory architectures reside in sharing constant data, not mutable one.

In any hardware architecture that features caches, and in any compiler whose memory model allows instruction reordering, synchronization of shared mutable data is always going to be problematic. So better do without that synchronization whenever practical.


> > 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.
> 
> Event-controlled architecture is exposed to generators (life-locks), and 
> no less to dead-locks and race conditions.
> 
>  From the software developing POV it is far worse than shared memory 
> architecture. The only advantage it has over the former that it can be 
> truly scalable while shared memory is a bottle neck.

I would claim that if your architecture is based on a notion of data ownership and favors the model of moving data over that of concurrently accessing it, then...

- Performance does not have to suffer (if what you move around is pointers or references to data, not the data itself)
- Race conditions in the message-passing process are easy to deal with (just do a memory fence before a thread sends data and after another receives it)

As for deadlocks in event-driven programs, they do occur, but they are trivial to detect (since the task graph is explicit, one can just look for a cycle in it), and good interface design can make it hard to trigger accidentally (if the event produced by a task A cannot be easily used as a dependency of that same task).