Re: Self-deadlock

["Stephen Maudsley, esgem" <Stephen.Maudsley@xxxxxxxxx>]

----- 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
guarded
> > 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
the
> > compiler could detect a definite path to deadlock, it ought still to
compile
> > the program (?) ... although issuing some concerned warnings might be
nice!
>
> 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
> casualties.

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