Real-time applications are cyclic in nature, and usually consist of processes that must execute well-defined chunks of work at specific rates. These chunks of work usually have strict deadlines to meet within the period of the process, meaning that each process requires a certain amount of the processor resource during its period. The requirements for each schedulable process can come into conflict with each other when system designers try to schedule a set of such processes to run on a single processor. Therefore, the system of processes must be designed carefully so that each schedulable process in the application gets the right amount of processor resource during its period. When designing such an application, the system designer must pay strict attention to the amount of execution time required by each process and the rate at which each process gets reactivated. These design points are made explicit in UniCon definitions of SchedProcess components (the SegmentDef property provides the system designer with the means to specify the amount of execution time required by the schedulable process, and the TriggerDef property provides the system designer with the means to specify the rate at which a schedulable process component gets reactivated).
The system designer must also take into account the available scheduling algorithms for a processor in the real-time environment when designing a system (the Algorithm property, specified in the definition or instantiation of an RTScheduler connector, provides the system designer with the means for specifying the particular real-time scheduling algorithm in
UniCon). Each available algorithm places a set of requirements on the schedulable processes. Some algorithms, for example, require that each schedulable process execute with a particular priority at run-time. For example, in the Real-Time Mach operating system, the rate monotonic scheduling algorithm gives the highest priority process that is ready for execution access to the processor resource immediately. For this algorithm to work properly, the schedulable processes in the system must be given priorities in accordance with their rates of execution. Processes with faster rates receive higher priorities.
The Priority property provides the system designer with the means for specifying the priority at which the schedulable process will execute in the environment at run-time. The value of the property is a non-negative <integer> in the range from 0 to 31. This range reflects the legal set of priorities that a process can have in the Real-Time Mach operating system.
The default value for the Priority property is the highest priority, 0.
Subsequent specifications of the Priority property in a single property list replace earlier specifications (i.e., the last specification is the one that the UniCon compiler uses).
INTERFACE IS TYPE SchedProcess PRIORITY (3) PROCESSOR ("TESTBED.XX.CMU.EDU") TRIGGERDEF (external_interrupt1; 1.0) TRIGGERDEF (external_interrupt2; 0.5) SEGMENTDEF (work_block1; 0.02) SEGMENTDEF (work_block2; 0.03) SEGMENTDEF (work_block3; 0.05) PLAYER timeget IS RPCCall SIGNATURE ("new_type *"; "void") END timeget PLAYER timeshow IS RPCCall SIGNATURE ("void"; "void") END timeshow END INTERFACEBelow is another example of a specification of a Priority property. It is embedded in an instantiation of the above SchedProcess component:
USES Client INTERFACE RT_Client PRIORITY (2) ENTRYPOINT (client) END ClientThe Priority value 2 in the Client SchedProcess instantiation overrides the Priority value 3 in the RT_Client SchedProcess definition.
Author:
Last Modified: May 12, 1996