next up previous top
Next: General
Up: Component Type
Previous: Process

SchedProcess

Semantics

The component type SchedProcess is a specialization of the Process component type. The semantics described for the Process component also apply to the SchedProcess component, except that a SchedProcess component does not represent an independently scheduled process in the operating system. It represents a process in a real-time operating system environment that is scheduled according to some real-time scheduling algorithm. This algorithm governs a set of such processes, all competing for the processor resource to meet real-time deadlines.

In addition to RPCCall and RPCDef players, a SchedProcess component exports players of type RTLoad. A player of this type represents a load that is to be placed on a particular processor (CPU) in the operating system environment. An RTLoad player is defined by a single trigger, and a set of segments, both of which are specified as properties in the player definition.

A trigger is an event that causes a process to become active and to perform its work. A segment is a well-defined block of that work. A trigger usually describes the expiration of a timer associated with a process in the operating system environment. The real-time scheduling algorithm interprets this as an event that requires the activation of the given process. Triggers are periodic; they happen over and over again at a given rate. For example, if a trigger has a period of one second, then the event occurs once per second. If the period is one half second, then the event occurs twice per second, and so on.

A SchedProcess component is broken down into a set of one or more work blocks called segments, each of which requires a specific amount of CPU time to execute. Collectively, the total execution time of the set of segments in an RTLoad player represents the load placed on the CPU by the SchedProcess component each time the event described by the trigger occurs.

In a real-time application described by a system of SchedProcess components, communication via remote procedure calls adds a level of complexity to the notion of an event. In such a system, a trigger activates only a client process. A server process becomes active whenever a request is made for a service it provides. When a process makes a remote procedure call, work blocks in a server process are executed in addition to the work blocks in the calling process. This means that, before work is completed in response to a given trigger, segments from a set of SchedProcess components will be executed if some of the processes are performing remote procedure calls. The specific sequence of segments that executes in response to a trigger is called the event trace. In systems of SchedProcess components performing RPCs, it is the load associated with an event trace that is considered during scheduling. To summarize, the RTLoad player in a SchedProcess component only describes the portion of a trace applicable to a single process. Since a trace can span multiple processes, the load placed on the CPU in response to an event comes from multiple RTLoad players.

In a SchedProcess component, triggers are defined and associated with periods by specifying a TriggerDef property in the property list of the component interface. Segments are defined and associated with execution times by specifying a SegmentDef property in the interface property list. Lastly, the specific trigger in an RTLoad player is specified by the Trigger property in the player's property list, and the set of segments is specified by the SegmentSet property in the same list. The trigger in the Trigger property must have been previously defined in a TriggerDef property, and the segments in the SegmentSet property must also have been previously defined in SegmentDef properties.

In real-time systems, not all of the work performed by SchedProcess components has the same priority. Some of the work is more urgent, and must always get priority over other work. To facilitate this pattern of execution, real-time operating systems make provisions for assigning priorities to processes. In UniCon, a priority is assigned to a SchedProcess component via the Priority property in the interface property list.

Player types

Players of the following types can be legally exposed in the interface of a SchedProcess component:

an exported remote procedure or function definition
a call to a remote procedure or function exported by another process
the execution-time and period information for the real-time process

Properties

The following properties can be legally included in the property list of a SchedProcess component. Properties legal in an <interface> property list have a C in parentheses after the property name; those legal in an <instantiation> property list have an I:

The syntax for an InstFormals property in a component of type
SchedProcess is a comma-separated list of <parameter>s enclosed in parentheses. A <parameter> consists of an <identifier>, followed by a `=', followed by a <complex string> or the language keyword NODEFAULT. A <complex string> is a simple "string" or a sequence of "string"s concatenated by the `&' character:

INSTFORMALS (first_parameter = "an initial value",
second_parameter = "a much" &
"longer initial value that " &
"will not fit on one line",
third_parameter = NODEFAULT)
The syntax for a Variant property in a component of type
SchedProcess is a single <identifier> or "string" surrounded by parentheses:

VARIANT (a_variant_name)
VARIANT ("a variant name")
The syntax for a Processor property in a component of type
SchedProcess is a single <identifier> or "string" surrounded by parentheses:

PROCESSOR (a_processor_name)
PROCESSOR ("a.processor.name")
The syntax for the EntryPoint property in a SchedProcess component is a single <identifier> or "string" surrounded by parentheses:

ENTRYPOINT (an_entrypoint_name)
ENTRYPOINT ("an entrypoint name")

If this property is omitted from the property list of the interface in a client SchedProcess component, the following default property is assumed:
ENTRYPOINT ("main")

If this property is omitted from the property list of the interface in a server SchedProcess component, no default is assumed.
The syntax for the InitRoutine property in a SchedProcess component is a single <identifier> or "string" surrounded by parentheses:

INITROUTINE (a_routine_name)
INITROUTINE ("a routine name")
The syntax for an RPCTypeDef property in a SchedProcess component consists of a sequence of three fields, all separated by semicolons, with the entire sequence enclosed in parentheses. The first field is an <identifier> or "string". The second field is also an <identifier> or "string". The third field is optional, and consists of a <size item> (if the third field is omitted, the semicolon following the second field is also omitted). A <size item> consists of an optional <array item>, followed by an <integer>. An <array item> consists of one or more consecutive <array index>s of the form `[` <integer> `]':

RPCTYPEDEF (a_type_name; "another one")
RPCTYPEDEF (a_type_name; another_one; 32)
RPCTYPEDEF ("a type name"; another_one; [25] [16] 32)
The syntax for an RPCTypesIn property in a SchedProcess component is a comma-separated list of items, surrounded by parentheses, that are either <identifier>s or "string"s:

RPCTYPESIN ("an_include_file.h", "another_one.h")
The syntax for a Priority property in a SchedProcess component is a single <integer>:

PRIORITY (12)
The syntax for a SegmentDef property in a SchedProcess component consists of two fields, separated by a semicolon, and enclosed in parentheses. The first field is a single <identifier> or "string". The second field is a single <floating point number>:

SEGMENTDEF (a_segment_name, 1.0E2)
SEGMENTDEF ("a segment name", 1.0E2)
The syntax for a TriggerDef property in a SchedProcess component consists of two fields, separated by a semicolon, and enclosed in parentheses. The first field is a single <identifier> or "string". The second field is a single <floating point number> or the word "asynchronous":

TRIGGERDEF (a_trigger_name, 1.0E2)
TRIGGERDEF ("a trigger name", asynchronous)

Semantic Checks

The following special semantic checks are made for SchedProcess components:

  1. A SchedProcess component that has a composite implementation may not contain an instantiation of a SchedProcess or a Process component.

  2. A SchedProcess component must expose at least one RTLoad player in the interface.

  3. A SchedProcess component describing a server process may not define any periodic triggers (i.e., triggers with non-zero periods).

  4. A SchedProcess component describing a client process may not define any aperiodic triggers (i.e., triggers with zero periods, or defined as "asynchronous").

  5. A SchedProcess component describing a client process must define at least one trigger and at least one segment.

  6. A segment defined in a SchedProcess component must be used in an RTLoad player exposed in the interface of that component.

  7. Each SchedProcess component in a system must be hooked to exactly one RTScheduler connector.

Implementation Considerations

The semantics of the underlying source code implementation of SchedProcess components are nearly identical to those of Process components except for the following:

Client processes must be implemented by C functions or procedures that do not loop forever. Since the real-time scheduling algorithm reschedules (i.e., reactivates) the code to execute over and over again, it must finish its work and return control to the operating system each time it is activated.

In addition to performing initialization to support remote procedure calls between processes, the "main" program for a process in a real-time environment must also initialize the process to run at a particular priority, and according to a particular rate (period). The priority information can be specified by the system designer in a SchedProcess component instantiation via the Priority property. The period information is specified via the floating point value in the TriggerDef property when defining a trigger in a SchedProcess component definition.


next up previous top
Next: General
Up: Component Type
Previous: Process

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996