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:
PAR
PRI PAR
a! w
b! x
PRI ALT
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. (b) The PRI ALT has to be in a loop. Strictly speaking for what you wrote, the loop would run twice:
PRI PAR
PAR
a! w
b! x
SEQ i FROM 0 FOR 2
PRI ALT
b? y
... respond to b
a? z
... respond to a
or more realistically
PRI PAR
WHILE TRUE
PAR
a! w
b! x
WHILE TRUE
PRI ALT
b? y
... respond to b
a? z
... respond to a
but if you wanted priority BETWEEN a and b
PRI PAR
WHILE TRUE
PRI ALT
a.event ? w
a! w
b.event ? x
b! x
WHILE TRUE
PRI ALT
b? y
... respond to b
a? z
... respond to a
These would not deadlock.
A loop around a PRI ALT that embraces all the ISRs in one high-priority process would do what you want:
I agree it achieves something similar, but it still presumes concurrency with the lower priority process. Communication with that process will be both contrived and potentially messy. How will the low priority process learn the counter value? We're back to channels between processes of differing priority, which is precisely what I wish to avoid. Combined, these have much more in common with sequential behaviour than concurrent.
Also, what if one of the lower priority processes in the ALT took a long time to complete. We will miss 'ticks'. It's not the behaviour I wanted.
"Concurrency with the lower priority process" is precisely what the whole world uses (in a disguised form) when splitting an ISR into a "hard" ISR and later-running soft ISR code. I think this is desirable, rather than the reverse, because you have to deal explicitly with state races that are unavoidable if the response to a stimulus can be longer than the spacing between (perhaps different) stimuli. Just having values change in the middle of the lower-priority ISR due to preemption by the higher one is usually undesirable. Some kind of FIFO needs to be set up.
Missing ticks need never happen unless the total time required to serve all the stimuli is more than 100% the time available. In a good design it should be less than 50%. There may be clustered ticks to which there is a delayed response using a FIFO.
Your proposal is anyway far less transparent than :
when
event a then
P
event b then
Q
…
idle
Z
where 'idle' equates with a SKIP guard. And I prize transparency above all else. The meaning ascribed to priority here is (IMHO) crystal clear.
The relative 'weight' of P and Q are immaterial.
See my comments above, about when event a pre-empts Q in the middle and changes an important value used by Q. Even if atomic code blocks are used in Q that is still bad.
Again, I have not described 'when' very well here, for which I apologise. The idea is that each clause is recursive (remains available after the termination of its guarded process) until it either disables itself or is disabled by a peer. The complete construction terminates only once all its member clauses terminate.
Yes, this does mean shared variables, but 1) we restrict these to a single construct (which can have a danger sign painted on it) and 2) we alleviate the risk with the restriction that only a single 'owner' can assign them. As we know, people have been building such systems around PVI for a very long time, with nothing more than a little care.
The care is to break interrupts into hard and soft parts, which is essentially the two-priority system!
When it comes to formal correctness, it's my understanding that CSP has difficulty with prioritisation anyway.
And I'd still like to keep prioritisation in a single construct (and thus interpretation) only. You've combined the two.
I'm not saying that my proposal is any way ideal, but just that there is a problem here (which may indeed relate to the difficulty the CSP folk have in dealing with prioritisation). (Incidentally, Bill Roscoe in UCS proposes establishing prioritisation over a system, in the form of a partial order. I'm not sure what the implications are for programming but I think he is saying "program without prioritisation, then impose one", without embellishing the language in any other way, then explore its behaviour (with FDR). I'm still not sure what the implications for programming are.)
Well, that does in a way make sense: round-robin interrupts and/or round-robin PRI ALTs, which amount to a fair ALT when used in a loop, and I do not believe I have ever seen a case where an ALT is not used in a loop. (There would have to be some way to insure exactly one of its communication partners did a send.) Then all prioritization would have to use explicitly coded booleans, and its consequences could be checked.
Larry
Ian
PS I shall have very little time from now for a few days, so may have to pass on further discussion, though I shall still read further posts. It's been fun, even if we've failed to convince each other!
Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)