From james_wolffe@ny.essd.northgrum.com Sun Oct 31 15:49:07 2004
From: james_wolffe@ny.essd.northgrum.com
To: occam-com@ukc.ac.uk
Date: Tue, 02 Mar 1999 08:17:57 -0500
Subject: Conflicting Priorities in occam
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
MIME-Version: 1.0
X-Mailer: ccMail Link to SMTP R8.20.00.25
Message-ID: <9903029203.AA920387422@internetmail.ny.essd.northgrum.com>

     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