The Trace property is used to specify an event in UniCon. An event is a thread of control through a set of schedulable processes running on a common processor that is initiated by some triggering mechanism in the environment and that eventually returns back to the environment. During execution, the thread of control is passed to a client schedulable process by the environment as the result of the firing of some triggering mechanism (e.g., a timer associated with a given process expiring in the kernel causing the scheduler to interrupt the currently executing process and transfer control to the given one). The process performs some work, and then 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. A trace is a specification of an 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 (in the order in which they execute).
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 the 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. 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.
The Trace property specifies a complete event. The value part of the property lists the trigger that initiates the event, followed by the segments that execute until control is returned to the environment (in the order that they execute). Although the SchedProcess components are what get managed by the real-time scheduler in the operating environment, the events are what are of interest to the real-time application developer. The events define the work that must be done in response to a trigger - the events have the associated periods, execution times, and deadlines. The real-time application developer designs an application so that all of the events in the system meet their respective deadlines. The SchedProcess components are assigned the appropriate work and priorities so that this will happen.
If the Algorithm property in an RTScheduler connector instantiation specifies the rate_monotonic scheduling algorithm, the UniCon compiler can facilitate a Rate Monotonic Analysis (RMA) on the events described by the Trace properties in that connector instantiation. For a RMA, the UniCon compiler collects the segment names, their execution times, and the period information for each event associated with a given processor; it also collects the priority information for each schedulable process associated with that same processor. It then formats this information and prepares a file containing input to a RMA tool which performs the analysis. This tool is invoked manually and reports a simple answer to indicate whether or not all of the events will meet their respective deadlines. The file that UniCon prepares with the input to the RMA tool is named RMA_<processor_name>, where <processor_name> is taken from the Processor property associated with the RTScheduler connector instantiation in which the Trace properties are specified. An RMA input file is generated by the UniCon compiler for each RTScheduler connector instantiation whose Algorithm property specifies a rate_monotonic scheduler.
There is no default value for the Trace property.
Subsequent specifications of the Trace property in a single property list are reported as errors. The UniCon compiler uses the first of the duplicate Trace properties it encounters. A duplicate Trace property is one in which the value part contains the same list of elements as a previously specified Trace property. Each Trace property value contains the same number of elements, and the elements in corresponding positions in the lists name the same trigger or segment.
USES Scheduler PROTOCOL RTM-Real-Time-Scheduler
ALGORITHM (rate_monotonic)
PROCESSOR ("TESTBED.XX.CMU.EDU")
TRACE (client.application.external_interrupt,
client.application.work_block1,
server.services.work_block1,
client.application.work_block2,
server.services.work_block2,
client.application.work_block3)
END Scheduler
CONNECT client.application TO Scheduler.load
CONNECT server.services TO Scheduler.load
The above example assumes that "client" and "server" are SchedProcess components that have been instantiated prior to the instantiation of the connector. Client has an RTLoad player named application that has a trigger named external_interrupt and three segments named work_block1, work_block2, and work_block3. Server has an RTLoad player named services that has two segments named work_block1 and work_block2. The example below makes the same assumptions.
ESTABLISH RTM-Real-Time-Scheduler WITH
client.application AS load
server.services AS load
ALGORITHM (rate_monotonic)
PROCESSOR ("TESTBED.XX.CMU.EDU")
TRACE (client.application.external_interrupt,
client.application.work_block1,
server.services.work_block1,
client.application.work_block2,
server.services.work_block2,
client.application.work_block3)
END RTM-Real-Time-Scheduler
Author:
Last Modified: May 12, 1996