I guess you are right. But this also means that the notion of PRI(ority) was screwed up.
It really meant "the first one in the list". Assuming that the second one on the list had a higher priority (which could not be specified) but was inserted later, it wouldn't have mattered. Hence the conclusion remains the same: assume nothing about the order or priority.
With a priority sorted list, this dilemma disappears. The priority is a system wide property (e.g. assigned to a task at design time following a RMA). When waiting on a priority sorted list, one gets the highest priority one that was inserted (before the waiting) even if inserted the last. Again, one should not assume anything about the order but at least now the highest priority one is received first. This mechanism reduces the blocking time for higher priority tasks in the system and generally improves the real-time behavior without affecting the logical behaviour, if correctly used.
Eric
From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Ian East
Sent: Tuesday, October 02, 2012 7:08 PM
To: Larry Dickson
Cc: Occam Family
Subject: Re: Programming prioritisation
On 1 Oct 2012, at 19:03, Larry Dickson wrote:
The problem arises when you compose PRI constructions in parallel with conflicting priority, which might arise through the pattern of communication across a network of processes. For example:
which deadlocks. (Excuse the tabs. I too favour 2-space indents, but not with variable width font.)
This still seems to involve a misunderstanding. (a) As written, the PRI PAR forces b!x to be low priority, the same as the PRI ALT, which I do not think is what you intended.
My recollection of PRI ALT is that priority decreases downward. 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.
All I'm after is a simple and transparent way to express pretty simple behaviour : ideally with one construction.
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)