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

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

Le samedi 2 juillet 2016 23:33:19 UTC+2, Niklas Holsti a écrit :
> On 16-07-02 19:49 , Hadrien Grasland wrote:
> 
> > 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),
> 
> That is not always enough. In my experience, event-driven programs tend 
> to have cycles where one task sends events or "requests" to another, and 
> expects "replies" in return. To understand if this causes a deadlock, 
> livelock, or works well, one must analyse the conditional control flow 
> in the tasks and consider the feasible/infeasible chains of events.
>
>
> > 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).
> 
> Good design is a cure for all kinds of deadlocks ;-)
> 
> I don't know if the request/reply event-cycle can be considered bad 
> design. In the examples I've seen, it was implied and required by the 
> roles assigned to the tasks. However, these were real-time, embedded 
> applications, not parallel computation applications.

In compute code, it is quite common to model a problem as a combination of many simple, single-purpose tasks (e.g. "blend two images together", "compute the histogram of the resulting picture").

In this kind of pipe-and-filter architecture, it is critical to have cheap task creation/scheduling and inter-task communication. But on the pro side, complex task synchronization is less frequently needed, because task tend to only interact indirectly through dataflow.

You avoid modeling I/O as "task A starts an IO task B, then sleeps until B has completed". You rather model it as "task A performs IO, and feed the output to task B, which is started as the result of all its inputs being available".

But indeed, I could well see this architecture being less appropriate for other scenario, such as the event loop of a real-time application or web server.