next up previous top
Next: Trigger
Up: Property
Previous: Signature

Trace

Description

The Trace property is used to further specify an RTScheduler connector instantiation in UniCon.

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.

Property Lists

The Trace property can legally be specified in the property list in the following UniCon language elements:

Value Syntax

The syntax for the value part of the Trace property consists of a comma-separated list containing a trigger name followed by one or more segment names, surrounded by parentheses. Trigger and segment names contain three dot-separated <identifier>s. The first <identifier> names a component instantiation, the second names an RTLoad player in the component instantiation named by the first, and the third names a trigger or segment in the RTLoad player named by the second.

Required Rule

Optional

There is no default value for the Trace property.

Merge Rule

ERROR

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.

Semantic Checks

The following are the semantic checks performed on the value of the Trace property:

  1. There must be at least two elements in the list that comprises the value of a Trace property.

  2. The first identifier in each element of the list in the value of the Trace property must name a previously instantiated component in the composite implementation in which the Trace property appears.

  3. The second <identifier> must name an RTLoad player in the component instantiation named by the first.

  4. The player named by the combination of first and second <identifier>s must be associated with a role in the connector instantiation in which the Trace property is found.

  5. The first element in the list must name a trigger - the third <identifier> in that element must name a trigger in the RTLoad player named by the second.

  6. All elements in the list after the first must name a segment - the third
    <identifier> in each of these elements must name a segment in the RTLoad player named by the second.

  7. A trigger used in a Trace property cannot be an aperiodic one - the period associated with it must be greater than zero (i.e., not "asynchronous").

Example

The following are examples of specifications of Trace properties. The first is embedded in an RTScheduler connector instantation, and the second is embedded in an <establish> of an RTScheduler connector:

  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

next up previous top
Next: Trigger
Up: Property
Previous: Signature

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996