In a real-time environment, client schedulable processes are periodic. They do not run forever. When a client process is activated, it runs to completion and returns control to the environment. Server processes, however, do run forever, but control is given to a server process only via remote procedure calls from clients or other servers. During execution, the thread of control is given to a client schedulable process by the environment. The process performs some work, and it may return or it may make a remote procedure call to another process (a server process). If it makes a remote procedure call, the thread of control is transferred to the server process, which performs some work and returns (or makes another remote procedure call, and so on). Control is eventually returned back to the original client process, where work continues in a similar fashion until control is returned back to the environment. This entire thread of control is called an event in UniCon, and can be described by a trace. A trace is a specification of the event. It specifies the trigger, the mechanism by which control is first given to a client schedulable process from the environment, and the sequence of segments that execute as a result of the trigger in the order in which they are executed.
A trigger is an abstraction. As mentioned above, it describes the mechanism by which control is transferred from the environment to a schedulable process. Only client processes can define triggers, because they begin execution by receiving control from the environment. Server processes do not have triggers because they execute continuously and receive control only as a result of remote procedure calls. Since client processes execute to completion and return to the environment, they can be reactivated by the environment according to some rate (i.e., some number of times per second). Therefore, triggers have associated rates of initiation. Triggers are defined in the interface property list of SchedProcess components via the TriggerDef property. The value part of the property defines the name of the trigger and associates with it the rate (in seconds) at which the trigger is initiated.
A segment is also an abstraction. It describes a chunk of code in the implementation of the schedulable process. The chunk of code it describes may take any form that the designer chooses. For example, it may describe a function, a set of functions, a portion of a single function, or even a few statements within a given function. The designer typically defines segments based on structural and execution time properties of the code in order to facilitate certain types of analyses that can be done on sets of schedulable processes in a real-time environment (more on this later). Segments are defined in the interface property list of SchedProcess components via the SegmentDef property. The value part of the property defines the name of the segment and associates an execution time (in seconds) with it. Work done in a schedulable process is described by a sequence of one or more segments.
As described above an RTLoad player corresponds to the load that a schedulable process places on the CPU of a given processor. A load is the total amount of execution time that a single schedulable process requires for execution of the code that it contains that applies to a particular event. An RTLoad player consists of a trigger (possibly) and a sequence of segments. This is described further below, but the discussion requires an example for clarification.
Assume that some real-time application consists of two schedulable processes: a client and a server. Assume further that the application consists of a single event in which the client calls the server for a service that it exports. The event is characterized by a trigger transferring control to the client process from the environment followed by: some code executing in the client, a remote procedure call from the client to the server, some code executing in the server, return of control to the client, some code executing in the client, and finally a return of control to the environment.
In this example, the client process defines a trigger. It is defined in the client SchedProcess via the TriggerDef property in the interface property list.
Additionally, each schedulable process has one or more segments. For simplicity we choose to define the segments as the chunks of code in each process that execute from the time control is given to the process until control is yielded. According to this scheme, the client process has two segments: the chunk of code that executes from when control is given to it by the environment until control is relinquished via the remote procedure call to the server, and the chunk of code that executes from when control is returned by the server until the client finishes execution. The server has only one segment: the chunk of code that executes from when control is given to it by the client via the remote procedure call until the server returns control back to the client. These segments are defined in each SchedProcess component via the SegmentDef property in the interface property list.
Lastly, each schedulable process defines an RTLoad player. The RTLoad player is specified with the Trigger and SegmentSet properties in the player property list. In the client
SchedProcess, the RTLoad player specifies a Trigger property containing the name of the trigger as it was defined in the TriggerDef property in the interface property list. It also specifies the SegmentSet property containing the names of the two segments that were defined in the SegmentDef properties in the interface. The RTLoad player in the server process specifies only a SegmentSet property with a single segment name in it, the segment that was defined with the SegmentDef property in the interface property list of the server. RTLoad players in server schedulable processes will typically never contain Trigger properties because they execute continuously. UniCon allows the system designer to define and specify triggers in server processes, however the period for such a trigger must be defined to be asynchronous.
To summarize, a load is described as the total execution time that a single SchedProcess component places on the CPU while executing code associated with a particular event, an event which executes in response to a specific trigger (occurring repeatedly according to a specific rate) in the environment. A load is described in UniCon by an RTLoad player, and there will typically be one or more RTLoad players defined in a schedulable process for each distinct event. RTLoad players are further specified by Trigger and SegmentSet properties.
NOTE: As mentioned above, segments are defined by designers based on structural and execution time properties of the underlying source code in order to facilitate certain types of analyses on sets of schedulable processes. One such type of analysis is a rate monotonic analysis (RMA). An RMA determines whether or not a set of events, scheduled in the environment according to a rate monotonic scheduling algorithm, will meet their deadlines. This analysis requires the rate information from the trigger of the event and the execution time information from all of the segments.
Author:
Last Modified: May 12, 1996