rwd@robots.oxford.ac.uk (Ron Daniel) (09/21/89)
I have a question concerning scheduling between PRI PARs and PARs. We
have a real time control task on a network of transputers being
performed by the PRI PAR which must send packets of data to other
processes. We have two ways of performing this:
PRI PAR
WHILE TRUE
SEQ
... external LOW LATENCY comms + little processing, always ready to run
IF
run.this.interval
SEQ
chan[0] ! data1
chan[1] ! data2
chan[2] ! data3
TRUE
SKIP
PAR i=0 FOR 3
WHILE TRUE
SEQ
chan[i]?local.data[i]
... A long process of [i]
the other is
PRI PAR
WHILE TRUE
SEQ
... as above
chan ! data1
chan ! data2
chan ! data3
WHILE TRUE
SEQ i=0 FOR 3
SEQ
chan ? local.data[i]
... A long process of [i]
At first site it would appear that the first version should allow the
PRI PAR to run with less latency in its comms as the second version
has to wait for communications to synchronise between each SEQ in
turn. Does the first method to behave in a `sensible' manner?
According to the Inmos Compiler Writer's guide, a low level process
will only deschedule under certain circumstances. Consider the following set
of events in version 1:
PRI PAR outputs data1 on chan[0], deschedules, and PAR [0] picks up local.data[0].
PRI PAR reschedules and tries to output on CHAN[1], but for further correct
operation in a `sensible' manner requires PAR [1] to schedule next to pick up
local.data[1], ie the behaviour of the PRI PAR with respect to latency now
depends on the order of scheduling of the replicated PARs. Is it good
fortune that the next process to schedule is always PAR i+1, ie the sheduler
chooses the process waiting on input rather the one that is free to proceed?
If the process which is ready to perform a complex SEQ was to be scheduled, the
PRI PAR would remain descheduled as its comms is blocked.
The point is, can the scheduling process make `intelligent' choices for the
next process to run so that it may complete its comms in the minimum time?
Is there some fancy proof that the PRI PAR always 'gets its channel'?
I can imagine a number of ways of organising the low priority PARs so that
it becomes necessary to search for the PAR with the other end of the channel
holding up the PRI PAR. Has anyone produced a set of guidelines on programming
practice to ensure `sensible' behaviour in the above example?
Thanks for any helpful hints etc.
Ron Daniel