Path: utzoo!attcan!uunet!decwrl!wuarchive!emory!hubcap!kddlab!icot32.icot.or.jp!hawley
From: kddlab!icot32.icot.or.jp!hawley@uunet.UU.NET (David John Hawley)
Newsgroups: comp.parallel
Subject: Re: Deadlock: Summary of responses
Keywords: practice, detection, avoidance
Message-ID: <9926@hubcap.clemson.edu>
Date: 31 Jul 90 13:17:29 GMT
Sender: fpst@hubcap.clemson.edu
Organization: Fifth Generation Computing Systems (ICOT), Tokyo, Japan
Lines: 45
Approved: parallel@hubcap.clemson.edu

In article <9917@hubcap.clemson.edu> masticol@lento.rutgers.edu (Steve Masticola) compiled:

>Sender: xeroxmailer!ALEX_HASSAN@ail.co.uk
>
>I write programs regularly using the Strand88 programming language. Strand88  
>is interesting from the point of view of synchronisation for the following  
>reasons:
>
>- When writing a Strand program, no explicit synchronisation code is required.
>This is because the language is based on data flow via single-assignment
>variables.
>
>- It follows that it is not possible to write a syntactically correct Strand  
>program that deadlocks or experiences any other form of synchronisation error.

Explicit or not, the syncronization code is still there.
More importantly, the dependencies are still there.

I program in KL1, a sibling of Strand.
I personally testify that both ...

>- In fact, what Strand does is to represent synchronisation errors as program
>errors - i.e. they are generally obvious and can be tested for by a simple  
>syntax checker, rather than being ephemeral quantities resulting in obscure  
>behaviour dependent on timing.

... stupid mistakes (forgetting to instantiate a variable, close a stream, etc)
and more erudite mistakes (race conditions) are possible in KL1.
I don't think Strand can be so different.
I would be delighted if someone would correct me.

>I think it will be interesting to see what responses you get to your request,
>as it is often quite hard to convince people how nasty synchronisation problems
>can be - that is until they encounter one!

I agree whole-heartedly ;-)

On a more positive note, I also believe that the concurrent logic languages
have a lot to offer in terms of simplicity and clarity, compared to
traditional ''sequential + concurrent_primitives'' approach.

---------------------------
David Hawley, ICOT, 4th Lab
csnet: hawley%icot.jp@relay.cs.net uucp:{enea,inria,mit-eddie,ukc}!icot!hawley
ICOT, 1-4-28 Mita, Minato-ku, Tokyo 108 JAPAN. TEL/FAX {81-3-456-}2514/1618