[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Programming prioritisation

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.


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