[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Conflicting Priorities in occam
Continuing this plot to fill Peter's mail box before he gets back tomorrow...
Reviewing our barrage of messages, I noticed:-
B.M. Cook writes:
> >If I understand what Barry is saying here, there is some distinction between
> > PRI ALT and PRI PAR which is not modelled in CSPP.
> I'm just saying that if 2 or more channels are ready to send data when an
> ALT is started, then PRI ALT chooses one of the channels on the basis of its
> own local ordering - irrespective of any priority that may, or may not,
> have been given to the outputting processes. This, effectively, assigns
> priorities to the channels.
But I claim that it ought not to respect only its local ordering, at least
not in hard semantics. After all, the inspection of the channels is exactly
examining its environment -- enquiring what the processes at the other ends
of those channels require. That is needed for hard priority.
But may be too expensive to implement in software.
I think, but haven't checked formally, that if *both* PRI PAR and PRI ALT
just react according to their own local priorities, then in a sequential
implementation that gives the non-determinism of soft priority.
That only works for a sequential implementation: the non-determinism
arises from the ignorance of which arbitrates first. A truely parallel
implementation of that algorithm would surely give hard priority.
Which is interesting. To obtain a hardware implementation of soft priority
would probably mean building a bias into the central arbitrator, yielding
a deterministic circuit.
Notice that again I claim that there is no distinction between PRI PAR
and PRI ALT here.
Anyway, I think that we have aired the issues and thrown up a whole new
March of hares. But my original simple question remains: how should we
define occam? I still claim that the existing Reference Manual is ambiguous
and someone ought to do something about it. *If* we are now the Guardians
of occam, and we now have the formal tools to do the job, does it fall to
us? If not us, then whom?
A E Lawrence, MA., DPhil. adrian.lawrence@xxxxxxxxxxxxxx
MicroProcessor Unit, 13, Banbury Road, Oxford. OX2 6NN. UK.
Voice: (+44)-1865-273274, Fax: (+44)-1865-273275