[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conflicting Priorities in occam

May I start a related, but lateral hare running?

This discussion brings back memories of a tentative discussion at a WoTUG
meeting last year, or the year before - I can't quite remember who was
taking part, Andy, Oyvind, ...?

Our conclusion was that we weren't at all sure that PRI PAR was the right
way to do things - we concluded (but were unable to give a really solid
reasoning for it) that priority was a property of a message, not a process.
This felt much closer to the needs of real-time systems.  This is what
PRI ALT does.

PRI PAR is a statement that there is a matter of sequence to resolve (not,
generally an issue with hardware - hence the current discussion). We
introduce sequence/PRI PAR in order to provide some response-time guarantees
for dealing with message communications. Maybe it would be better to
annotate these needs (maximum response times, data rates, ...) rather than
try to provide them at second-hand. (Isn't this what we do with things
like rate-monotonic scheduling? Disclaimer: I might be very wrong with this,
it's on my list of "must find out more" but time hasn't yet permitted.)

By having both PRI ALT and PRI PAR, we can build systems with conflicts (as
Adrian shows), and we should have something like a usage rule to notice it.
Or, we dispose of PRI PAR (it's pretty meaningless on hardware and
multi-processor systems) and do something more fundamental (i.e. use occams
razor) - if indeed there is something more basic.

Yes, I know that priority processes are traditional, but as a result, so are
problems such as priority inversion.

Whichever route is used we'll still need things like (over-writing) buffers
to change priorities but maybe we can better direct their use (it's the
option to leave them out that helps us build non-working systems).

[That should stir up some opinions, I hope.]


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