[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Programming prioritisation
Ian East wrote:
I'm struggling to see the problem here - which may just mean it's too
long since I did this stuff.
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.
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
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.
Software Manager & Engineer
Tel: 01223 414180