Re: Is PRI PAR useful for hardware?

["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.

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.

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.

> Do we need anything like this? What was the problem that the "priority
> on events" debate addressed? Anyone?

Maybe this is close to the same as the primary factors I suggest above.

	 Barry.

-- 

/----------------------------------------------------------------------------\
| Barry M Cook, BSc, PhD, CEng, MBCS         Department of Computer Science, |
| Chartered Information Systems Engineer.    Keele University,               |
|                                            Keele,                          |
| Phone: +44 1782 583411                     Staffordshire,                  |
| FAX:   +44 1782 713082                     ST5 5BG,                        |
| email: barry@xxxxxxxxxxxxxx                UK.                             |
\----------------------------------------------------------------------------/