From: phw (P.H.Welch_at_email.domain.hidden)
Date: 1997-09-30 22:17:48
Hi Oyvind,
There was some stuff on limbo on occam-com last June. I took hard copy
of the limbo reference manual to read on my flight to the States that
month and talked to some of the participants at the Java workshop we
ran at the PDTPA'97 conference in Las Vegas. I corresponded with one
of them afterwards and enclose the relevant fragment below.
It's not credible that the designers of Limbo were unaware of occam.
Not only do they support some of the same concepts as central ideas
within the language, they even use the same key words for them --
`chan', but more significantly `alt'. OK, they changed to lower case
but an appeal to coincidence is a bit far-fetched!
I like what I read about Limbo, but they do seem to have made some
basic errors that could have been avoided by some serous discussion
with the occam community ;-( ...
It just shows how far we have to go to get occam the credit it deserves
and bring to people's notice that it is alive and moving forward :-) ...
You are welcome to copy my comments to Larry Rau if you feel it may
help. It would be nice to open up discussion with the Limbo people.
Cheers,
Peter.
cc: occam-com
(cut here)
-----------------------------------------------------------------------------
There are 3 big problems (with Limbo) off the top of my head:
1. they allow outputs in ALTs. This topic was thrashed to death in
the mid-1980s. CSP allows a free mix of input/output guards and
there is no semantic problem. But there is a huge run-time penalty
in supporting it ... the problem is when both parties are ALTing
off a channel between them ... getting both sides to agree about
whether to take the communication when both sides can back off.
It can be done, but in general you need a third party to referee
and that gets expensive. Solution: only allow only one party to
a communication to back off. In occam, only inputters can back
off and that does the trick. In over a decade's industrial use,
this has *never* proved to be a serious contraint on design. And
we can keep overheads really low ...
2. they don't allow pre-conditions on ALT guards. This is trivial
to implement, adds no significant overhead and enables much more
simple designs. E.g. take a look at their blocking FIFO. They
do some wonderful, but *weird*, stuff to ensure that consumers can't
consume when the buffer is empty, and producers can't produce when
the buffer is full. With pre-conditions on the ALT channels, it's
easy!
3. there is no attempt to address the implicit non-determinism
resulting from uncontrolled race-hazards on data shared between
parallel processes. This is one of occam's supreme contributions
to parallel computing and one that is crazy to throw away.
Nevertheless, the world seems content so to do.
4. (this is political) there is no acknowledgement anywhere (that I can
see) in the Limbo reference manual to either CSP or occam. Yet they
have lifted precisely two of their fundamental ideas -- the zero
buffered synchronised channel and the ALT (although they damaged
the ALT). They have even used exactly the same keywords!
The reason this is important to us is that we are continually getting
damaged by funding/paper reviewers who say to us: "Gee, that may be
good stuff, but nobody's interested in those ideas any more -- go away!".
With a lively interest in the States, they couldn't say that any more.
But if the Limbo people don't acknowledge where the ideas came from,
we suffer ...
Limbo and the occam/CSP communities should have lots to offer each
other. Please let's do this!
I think there were some other, minor, problems with Limbo channels and
ALTing but I'll have to get back to you on that.
If you wish, please forward the above to the Limbo/Inferno newsgroup ...
what's its name please?
[Note: I don't know if the above happened ... nor the name of the newsgroup]
This archive was generated by hypermail 2.1.7 on 2004-10-31 20:03:56 GMT
© Copyright WoTUG
All rights reserved