From: james_wolffe_at_email.domain.hidden
Date: 1999-03-02 13:17:57
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
following:
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.
and
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 practical
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 to any processor set.
Historically, resource issues have been handled outside the scope of
the concurrent program. Resource sharing is typically handled with
interrupt routines and 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 processes are mapped where.
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 when it is
mapped onto certain processors.
Jim
-------------------------------
James Wolffe
Sr Member Technical Staff
Northrop Grumman Norden Systems
Melville MY USA
This archive was generated by hypermail 2.1.7 on 2004-10-31 20:03:57 GMT
© Copyright WoTUG
All rights reserved