[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x2AnyChannels do not allow alting
Peter wrote:
> In CSP, the PAR operator is defined in terms of external choice (sort of
> ALTing). In occam, we all know the following equivalencees:
>
> PAR == ALT
> in0 ? x0 in0 ? x0
> in1 ? x1 in1 ? x1
> in1 ? x1
> in0 ? x0
I didn't!
Maybe it's a question of what "==" means, see below.
Admitting that my CSP isn't all it should be, I may need my thinking
straightening out (please help), but I've been interpreting this differently.
My interpretation ...
The ALT case indicates that we either do SEQ( in0?x0; in1?x1 ) or
SEQ( in1?x1; in0?x0 ) which give the same result as each other and as
concurrent execution of both inputs. So, the ALT form is a valid
IMPLEMENTATION of PAR, but not the only one - true concurrency is also
valid.
When converting the PAR case to hardware I really do allow all paths to be
concurrent - it's easy, it's natural, it boosts performance, ... Although I
am happy that sequentialisation is needed on a single processor, this is
surely not a good equivalence for multi-processor systems, is it?
I'd prefer the == to be "may be implemented by" rather than "is the same
as". Maybe my problem is that I'm just misinterpreting the meaning of "=="
as used above and it does mean "gives the same result as" ("equals" is
seriously overloaded in mathematics/computing!).
Barry.
--
/----------------------------------------------------------------------------\
| Barry M Cook, BSc, PhD, CEng, MBCS |
| Senior Lecturer, Department of Computer Science, |
| Chartered Information Systems Engineer. Keele University, |
| Keele, |
| Phone: +44 1782 583411 Staffordshire, |
| FAX: +44 1782 713082 ST5 5BG, |
| email: barry@xxxxxxxxxxxxxx UK. |
\----------------------------------------------------------------------------/