[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
----- Original Message -----
From: "Denis A Nicole" <dan@xxxxxxxxxxxxxxx>
To: "P.H.Welch" <P.H.Welch@xxxxxxxxx>
Cc: <Oyvind.Teig@xxxxxxxxxxxx>; <occam-com@xxxxxxxxx>
Sent: Wednesday, April 05, 2000 12:26 PM
Subject: Re: Self-deadlock
> On Wed, 5 Apr 2000, P.H.Welch wrote:
> > An ALT with no guarded processes - or an ALT with pre-conditioned
> > processes all of whose pre-conditions are FALSE - is a perfectly legal
> > program in occam. Similarly, occam does not attempt to outlaw deadlock.
> > A deadlocking occam system is still a legal occam system. So, even if
> > compiler could detect a definite path to deadlock, it ought still to
> > the program (?) ... although issuing some concerned warnings might be
> Yes, just like SPoC. The deadlock _is_ detected at run time. This
> correctly distinguishes it from divergence.
> > So, two questions:
> > 1. if the compiler can detect deadlock, should it reject the program?
> It should warn.
> > 2. should we be looking to develop languages whose syntax/semantics do
> > not allow the writing of programs that deadlock?
> We should be developing tools that allow us to detect deadlock and other
> undesirable behaviours by static analysis and model checking. I am.
> Deadlock is not a big issue for parallel correctness; there are much
> worse and more insidious failure modes. As deadlock is detected at run
> time, appropriate failure mitigation can take place. Eg, deadlock on an
> in-flight 747 can trigger a self destruct so as to prevent ground
Isn't that why they run some of the wiring through the fuel tanks?
-- Stephen Maudsley mailto:Stephen.Maudsley@xxxxxxxxx
-- +44-1453-521626 mobile: +44-370-810991