Re: Conflicting Priorities in occam

[james_wolffe@xxxxxxxxxxxxxxxxxxxxx]

     James Wolffe wrote:
     
     > 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.
     
     Peter Welch Responded:
     
     But I think that PRI PAR, as used above *within* a single processor on 
     which a particular functionality has been mapped, gives us a 
     sufficient handle with which to manage things - at least for 
     rate-monotonic schemes or any scheme in which the priority of a 
     process is fixed.  The reasons for wanting dynamic priorities -- e.g. 
     to fix the prioriy inversion `problem' or for deadline scheduling -- 
     look weak.  If we "bury" the notion of priorities within some runtime 
     support package, we are only putting off the problem. What is the 
     semantics of that package?  With CSPP, we are begining to get the 
     semantics of PRI PAR.  This is good news ...
     
     -----------------
     
     On looking at this exchange, I am quite certain that what I meant to 
     say didn't come out as intended. Indeed, exposing priority issues in 
     the language is "good news". Sorry about the poor exposition, but now 
     let me try to straighten things out a bit....
     
     My main idea was that a program design should capture the solution to 
     some set of real time requirements, regardless of how the process 
     components are mapped to pieces of hardware or programmable 
     processors. So, any local notion of priority should be derived from a 
     global set of priorities contained in the source code, and would 
     therefore be resolved by mechanisms outside of the program text; i.e., 
     in the "runtime support" as generated by the compiler and linker in 
     accordance with mapping directives.  
     
     This idea involves the use of a global priority level attached to 
     every process, so that whenever resource contention arises at a 
     particular processor, it is always resolved according to the relative 
     order implied by the global priorty "tag" implicitly attached to each 
     process. The global priority level appropriate to each process can be 
     established using Rate Monotonic Analysis (RMA) over the program as a 
     whole, independent of the mapping. 
     
     So, what this reduces to is "burying" priority issues at the level of 
     an individual processor, but fully exposing it at the highest levels 
     of program design. I think the challenge is to maintain the right 
     "compositional semantics" when nesting several independently specified 
     software subsystems (each with their own global priorities) to form a 
     larger composite application. Some sort of priority adjustment and 
     "interleaving" procedure may be needed to join several different sets 
     of priority specifications into a single new RMA-based solution.
     
     Jim
     
     -------------------------------
     James Wolffe
     Sr Member Technical Staff
     Northrop Grumman Norden Systems
     Melville NY USA