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

Re: Programming prioritisation

On Oct 2, 2012, at 10:08 AM, Ian East <ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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:

a! w
b! x
b? y
... respond to b
a? z
... respond to a

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.

The loop (with two members) is absolutely required for any form of ALT to make sense in this example. Otherwise one of the PAR members is hung. Remember that the ALT selects only one out of its list (it behaves like an IF, not like a PAR), whereas your PRI PAR sends two communications.

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.

I agree this could be a problem if there are half a dozen or more branches in the ALT, in which case a many-to-one channel may be best. But prioritizing usually has little effect. The separation of interrupt service routines into "hard" and "soft" parts (in Linux called "top half" and "bottom half") adds a little extra coding, but the reward is huge, giving real-time assurance of responsiveness and coded assurance of software-enforced priority. That is why everybody does it --- and therefore everybody really uses the two-priority system.


 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.


Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)