Re: Priority revisited: a new primitive

[p0072370 <ireast@xxxxxxxxxxxxx>]

Greetings O occam-volk

>Coming from a hardware implementation angle, I still have difficulty with
>"PRI PAR" which appears to be a complete oxymoron.
>
>Its behaviour (in the non-preemptive case - not that there is any indication
>of preemptive or not, it's left to the implementation) is:
>
>    SEQ i=0 FOR number of "parallel" processes
>      Choose the highest priority process
>	Do it and disable it
>
>Which doesn't look very "PAR" to me!
This is not the condemnation I would make. PRI PAR is expressing queue 
semantics - a priority queue, rather than a simple one. The availability 
of N processors would merely allow the first N processes in a priority 
queue to run simultaneously. Remember, however large N is, it may still 
be less than the number of processes. We're covered either way.

I would choose to damn this construct because it introduces a SECOND 
prioritization, and one that is only vaguely defined, even at the 
intuitive level. At best, it might indicate a prioritization of the first 
event of each process. But then we can already prioritize behaviour by 
event using PRI ALT.

I believe priority should be associated with events, and events only. 
That is both intuitively clear and (potentially) semantically more 
tractible. Surely, this is all we need when we design any system - to 
enable response to events according to their priority. If all processes 
truly run in parallel, there is no problem.

A problem only arises when we account for the possibility where there may 
fewer processors than processes. There is then the need for a global 
measure of priority. This is how I model what PRI PAR is doing. But it 
does it very clumsily. In...

  PRI PAR
    A
    B

...response to ALL events in A receive a higher effective priority than 
that to any in B. What if A is our flight control system and B is our 
defence? Think I'd get out and walk!

Over the years, I've missed a lot of the occam discussions due to other 
activities and interests. Have any of the real-time volk previously 
complained, or proposed better solutions?

We seem to be accumulating a wish-list for a new language...

Ian


Dr. Ian Robert East
01865 483635
Room T656, Tonge Building
School of Computing and Mathematical Sciences
Oxford Brookes University

2000/2001 Term 1 Consultation hours:
Tuesday   11.00..12.00; 12.00..13.00
Friday    10.00..11.00; 12.00..13.00