Re[2]: Conflicting Priorities in occam

[james_wolffe@xxxxxxxxxxxxxxxxxxxxx]

     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 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 
  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 on certain 
  processors.
  
  Jim
  
  -------------------------------
  James Wolffe
  Sr Member Technical Staff
  Northrop Grumman Norden Systems
  Melville MY USA