| Hello Ian,
A few practical details, which seem to be ignored (or maybe they are so obvious to everyone else that nobody mentions them) ... Hi Øyvind
I certainly referred to Bill Roscoe's second book on CSP, which he describes as part sequel, part successor, to his original Theory and Practice of Concurrency :
Roscoe, A. W. : 2010, Understanding Concurrent Systems, Springer ISBN 978-1-84882-257-3
I mentioned the one section on priority in the book (#20.2 Priority, pp. 486-496 (though there is a brief mention earlier in the context of timed systems), where he rejects prioritised choice (PRI ALT) because it presents problems "when the priority orders of different parallel processes cannot be resolved".
There is no practical problem at all, if the individual disable instruction in the ALT is atomic. For instance, if the ALT is in a low-priority Transputer process, a high-priority interrupt has to happen either before it or after it. If before (its own) disable, then the priority of the ALT wins. If after, then the timing of the come-ready is the winner. I do not believe there is any ALT scheme where the lower-priority sender does not win if it comes ready significantly before the higher-priority one and after the ALT is enabled.
However, other-process priority can make a difference if it can interrupt the ALTing process while a same-level or lower-level priority has to "wait in line" before it can communicate ready.
I managed a brief chat with Gavin Lowe, whose thesis concerned prioritisation, and suggested I really ought perhaps to read his thesis first. He recommended instead starting with his more recent papers, as they were more up-to-date.
From these contributions, this discussion (thread), and my own thoughts, I think there are two clear conclusions thus far : 1 in the presence of many low-cost processors ('cores'), we can usually forget prioritisation in practice 2 where a programming language does incorporate prioritisation, it is better to prioritise events (and their response), in which case there must be an opportunity to declare a partial order over the events concerned over the scope affected.
I remain concerned that the first approach may sometimes result in a more complicated communication pattern which may be more difficult to program (or, conversely, invite more error).
I have yet to fully understand the consensus (if there is one) in the CSP community over programming prioritisation.
Ian
Clearly (according to this thread) there is none ;-)
But David, I think, is basically right. If the hardware has enough asynchronous responsiveness and bandwidth to keep well ahead of the stimuli and real-time requirements, the problem is soluble whatever the prioritization tools. If not, you are in deep cow product no matter what scheme you use. This implies that KISS is the best design principle.
Larry |