Re: Priority revisited: a new primitive

[A E Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Here is a slightly more complex example where there are two levels of
priority, exemplified by two events, a and b:


Using pseudo-occam,
 
PAR PRI [{a},{b}]
  P1
  P2
  ..
  Pn

is equivalent to (=) 
 
PRI PAR
  SEQ
    sampling := TRUE
    WHILE sampling
      PRI ALT
        a
          SKIP
        b
          SKIP
        done
          sampling := FALSE
  SEQ
    PAR
      P1
      P2
      ...
      P3
  done

Again the equivalence holds only when a and b synchronize with the Pi's.
I haven't checked this properly against the denotational semantics that
I have in mind, but I think that this is ok in a trace semantics. The
point is that if there are sufficient resources available (enough
processors),
then a and b might be executed "together" if they are offered
simultaneously.
But a trace would show them happening sequentially (in a particular
order): it can do no other. The intuition would be that they happened
"very close together".
This applies to all the other sorts of events that might be available
concurrently when there is more than one processor or resource. 

I hope that this show a little more clearly that the semantics is clear
and simple and is easy to reason about. 

Implementation is, of course another matter. A simple minded and
absurdly slow scheduler is straightforward?

Adrian
-- 
Dr A E Lawrence