From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: RFC: Prototype for a user threading library in Ada
Date: Sun, 3 Jul 2016 00:33:17 +0300
Organization: Tidorum Ltd
Message-ID: <dtqq8tFb4spU1@mid.individual.net>
References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com>
 <dsim6eF91ubU1@mid.individual.net> <nk19hh$o33$1@gioia.aioe.org>
 <d9d7f8f5-8b72-450b-8152-4b6116c6ce2c@googlegroups.com>
 <nkfeqn$nl8$1@franka.jacob-sparre.dk>
 <f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com>
 <nknh11$bvg$1@franka.jacob-sparre.dk>
 <1e32c714-34cf-4828-81fc-6b7fd77e4532@googlegroups.com>
 <nl7gbk$41a$1@franka.jacob-sparre.dk>
 <bb07afac-5eaf-4622-b264-da6aef96e8d6@googlegroups.com>
 <nl8evv$vha$1@gioia.aioe.org>
 <f7fddb06-2cde-4982-baf1-3b1a83e26106@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net EbehZ0lxmI0pnG+kLGaoRQ5itiodv3ZsE5PlgvPAfroHN8fJtK
Cancel-Lock: sha1:TpNf650FQN975uf+l8xga7uglCY=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.1
In-Reply-To: <f7fddb06-2cde-4982-baf1-3b1a83e26106@googlegroups.com>
Xref: news.eternal-september.org comp.lang.ada:31009
Date: 2016-07-03T00:33:17+03:00
List-Id: <comp.lang.ada>

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .