[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Conflicting Priorities in occam
Barry Cook wrote:
"1) PRI ALT is a way of declaring an "urgent" channel
2) Except that if the process receiving the message is low priority, then
"urgent" may take a long time to be received."
My top level interpretation of the PRI ALT and PRI PAR issues is the
1) PRI ALT is necessary (or at least useful, and apparently free of unusual
problems) to express ordering preferences. It seems to be safely usable in all
cases (hardware or software, uniprocessor or multiprocessor), since its scope
is always local to a single thread of control on a single processor, whether
hardware or software.
2)PRI PAR is a very difficult thing to get right, since it reflects the desire
to share a processor resource, normally a very implementation-dependent issue.
Except for control of resource sharing I see no good reason to support it.
Unfortunately, controlling the effects of resource sharing is a critical issue
in concurrent real time systems
The resource sharing issue would ideally be kept independent of the design of
correctly functioning programs. With a sufficient total quantity of available
processing resources, whether hardware or software, a given correctly-
functioning concurrent program should be mappable without change.
Historically, resource issues have been handled outside the scope of the
concurrent program. Resource sharing is typically handled with process
priorities (and inheritance) on uniprocessors. Little observable success has
been achieved in dealing with resource sharing across multiprocessors.
So, I see process to processor distribution (mapping) as the way that hardware
processes are joined to timing specifications. A unified framework would
certainly be welcome, but I don't think that PRI PAR alone meets the
requirements here. The priorities assigned would probably need to be local for
efficiency, and that of course depends on which concurrent process are mapped
Bottom line: I see two independent areas fcr real time program specification:
logical (consisting of occam including PRI ALT, but without PRI PAR), and
temporal (relating processor performance capabilities and the process mappings
to the timing requirements placed upon the logical design). PRI PAR styled
priority functionality would be "buried" inside the runtime support package
for a given as-mapped system. That is, the need for priority is a side-effect
of meeting the timing requirements of the concurrent program on certain
Sr Member Technical Staff
Northrop Grumman Norden Systems
Melville MY USA