Re: Programming prioritisation

[Ruth Ivimey-Cook <ruth@xxxxxxxxxx>]

Ian East wrote:
> I just wanted to show how simple it is to program a conflict in 
> priority :  here, the PRI PAR prioritises channel 'a', and the PRI ALT 
> channel 'b'.  No loop required for a problem to arise.
>
> True, the two processes should not deadlock, but they will have to 
> engage in some sort of negotiation, which is likely to be inefficient 
> and will require some ancillary protocol for resolution.  My point is 
> just that this is best avoided.
I'm struggling to see the problem here - which may just mean it's too 
long since I did this stuff.

The problem as written is just a broken protocol and nothing to do with 
PRI or ALT. The only relationship I see is that the ALT construct itself 
might make it look as if things will work ok because both channels are 
mentioned.

The ease of writing this stuff is why (correctly) Peter is suggesting 
that Occam-next has explicit support for protocols, rather than just 
individual communication, which IMO should have been added much earlier.

Ruth

--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/