Re: Is PRI PAR useful for hardware?

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

All,
   I've been following this PRI PAR exchange (like a tennis ball whizzing
around) and my reaction has been much like Barry Cook's, below. But first
let it be clear that I'm happy how it has livened up occam-com ... even
if it does fill up my mailbox.

>Subject: Re: Is PRI PAR useful for hardware?
>To: adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (A E Lawrence)
>Date: Mon, 26 Apr 1999 21:43:45 +0100 (BST)
>Cc: R.Peel@xxxxxxxxxxxxxxx (Roger Peel), occam-com@xxxxxxxxx
>From: "B.M. Cook" <b.m.cook@xxxxxxxxxxxxxx>
>
>A VERY brief reply - from home, looking at ~200 messages and trying to
>filter them!
>
>> Anyway, what I was really trying to extract from you or Barry or Andre
>> (the main advocates?) was some clearer idea of what the alternative to
>> PRI PAR might be. I thought that it was more general than hardware?
>> Wasn't the original concern with real time scheduling in software? With
>> some idea of dynamic priority: hence my recent note. But perhaps it is
>> still a vague notion not concrete enough to state clearly?
>
>Of all the examples I've seen, so far, I've seen nothing that indicates the
>user should ever write PRI PAR - PRI PAR is always used to force the machine
>into an implementation of something higher level ... and I'm sure that is
>wrong, it is for compilers to determine exact implementations and we should
>write at as high a level as possible.

That's very limiting, Barry. In a multiprocessing system, for instance, I
should be free to design to a heterogeneous array of my choice, including
very different processors mapped in more or less fixed fashion to blocks of
code. I then want to impose the implementation at that block level, not have
the compiler mysteriously decide it.

PRI PAR (as used in transputers) is similar in that it treats the machine as
two machines - interrupt and timesharing - which behave somewhat differently.
This was extremely useful and nearly optimal in many real implementations -
and with good coding practices you lost very little by not prioritizing
interrupts (using a strategy like Unix "bottom halves"). It's hard to justify
more than two "machines" though, which when you go to a general PRI PAR then
leads you to the highly COMPLEX techniques being discussed - commercial RTOSs
have been in this morass for years.

>
>I am finding that the higher level is more along the lines of "this process
>must be run N times a second" or "the response time to this event must be no
>more than S seconds" - and relative priority of processes can be derived
>from them for each specific implementation - PRI PAR is a secondary
>characteristic, not the primary driving force.

So what you are talking about could be called responsiveness rather than
priority.

>
>Andy's paper at WoTUG22 expounds this further.
>
>> My suspicion is that PRI PAR will do the job perhaps in conjunction with
>> a new primitive along the lines of the CSP interrupt operator. The point
>> is that we can abort [perhaps I mean suspend] an active process: then it
>> might be continued in a different branch of a PRI PAR. Since there are
>> no additional resources required, this ought work with static memory
>> allocation. And so be compatible with occam. And the CSP(P) semantics
>> will allow us to design the occam extension properly; and stay with a
>> well defined mathematical model.
>
>My BIG concern is that as soon as PRI PAR appears we have effectively fixed
>the implementation - this is not what we should be doing.
> .....
>  Barry.

Remember that using the transputer's PRI PAR you can get much the same
effect by considering transputer-high-priority (which is really interrupt
priority) to be at infinite priority, and communications from infinite
priority can control the responsiveness of frequently swapping
timeshare-priority processes. The key here is that the bandwidth consumed by
infinite-priority processes should be nearly zero. Possibly what needs to be
controlled is the frequency of timeshare swapouts. If swapouts are more
frequent that allows responsiveness to be controlled more precisely.
   Larry Dickson