Re: Priorities in SPoC

[Denis A Nicole <dan@xxxxxxxxxxxxxxx>]

On Mon, 1 Mar 1999, Adrian Lawrence wrote:

> Ah, so SPoC *does* have priority. Excellent. And that "critical error" is
> exactly the right behaviour when it hits a STOP. CSPP says the soft priority
> gives  (a -->STOP) |~| (b --> STOP), and SPoC has done the second, hit the 
> STOP, followed occam philosophy and warned of an error. Good old SPoC.

Less about the old...it's still under active development you know.  Apart
from assorted bug fixes, we now have flattening (elimination of
replicators, PROCs and FUNCTIONs) working and can generate PIC assembler
with minimal per-process state.  This will also make the SMV
model-checking feature work properly sometime soon. 

With other people's work on occam to FPGA, we are close to a complete
integrated HW/SW codevelopment world for occam.


Anyway, the real reason for the message was to discuss SPoC's
implementation of PRI.  The SPoC scheduler essentially uses coroutines; it
is not preemptive.  When it gains control, which includes every
communication and PAR, it uses two queues, high and low priority, as in
the transputer. The high priority queue is always run if possible. 
Without external communication, a high priority process can _only_ become
ready at a scheduling point, so this model ensures that there is never a
high priority process waiting on a low priority one.  The scheduler has no
preemption, so this guarantee cannot be provided for _external_
communications triggering a high priority process. 

ALTs are all PRI ALTs of the transputer sort, complete with the famous
three-way PRI ALT bug (feature).  SPoC goes to great lengths to ensure
transputer compatibility... 

Denis A Nicole                      WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan 
High Performance Computing Centre   Email: dan@xxxxxxxxxxxxxxx                  
University of Southampton           Phone: +44 1703 592703                      
UK.                                 Fax:   +44 1703 593903