The analysis presented in this chapter is used to schedule the individual actors, such that an actor is described as a set of static schedules, which are fired based on the guard of the first action in the schedule. This is useful for predicting the schedules to be constructed for the actor partitions, described in the following chapter. The reason for why this in needed, is that, in order to search for a schedule, we need to define how much work the schedule is supposed to perform; this can be in terms of how much input tokens are consumed or a partial description of which actions must fire during the schedule. By first scheduling the individual actors, the static firing sequences of the actors (see Figure 4.7) gives a limit of how many actions can fire before a dynamic guard expression must be evaluated, similarly the token rates of these sequences and the more precise descriptions of the states are known as a result of this.
In practice, this analysis is performed as a set of analysis passes run by the Orcc compiler as part the Promela code gereation. In addition to generating the Promela code, also some additional information, which is used by the scheduling tools outside Orcc, is generated. While, how this
<actor name=”d c p r e d”>
<schedule i n i t s t a t e =”read ” action=” s t a r t ”> <rates>
<peek port=”BTYPE” value =”2048”/> <read port=”BTYPE” value=”3”/> <write port=”START” value=”1”/> </rates>
</schedule>
<schedule i n i t s t a t e =”read ” action=” r e a d o t h e r ”> <rates>
<peek port=”BTYPE” value=”0”/> <read port=”BTYPE” value=”1”/> <read port=”QP” value=”1”/> <write port=”START” value=”1”/> </rates>
</schedule> . . .
</actor>
Figure 4.8: The generated information regarding the token rates and values of the actor level schedules.
information is used is presented in the next chapter, this section presents the actual information generated by the analysis.
The first part, the actor level schedulers, describe the schedules of each of the actors, and more importantly, the states where a dynamic scheduling decision is needed. An example of the generated actor level representation is shown in Figure 4.7; this actor is simplified to an FSM with only one state and one transition corresponding to an action firing sequence. From this actor, it can be seen that one iteration corresponds to 65 action firings, and ideally, a schedule for a partition including this actor also includes the corresponding sequence, possibly interleaved with sequences from other actors.
To construct the scheduling model of a partition, it is also useful to have some additional information regarding the actor level schedules. Figure 4.8 shows the information generated regarding token rates and values that is used to generate the appropriate input sequences for a partition of actions that are analyzed for composition. While the values of read and write de- scribe the number of tokens consumed and produced on each of the ports when a schedule is fired, the value of peek describes the actual value that is accepted by an input dependent firing rule, based on the approach in [124]. Finally, the last piece of information, is the refined description of the actor state which is used to compare if two states of an actor are identical from a scheduling point of view. An example of the this, as it is generated by
<actor name=” z i g z a g ”> . . . <state> <a l l s t a t e s > <v a r i a b l e name=’ count ’/ > </ a l l s t a t e s > <fsmstate name=’ f u l l ’> <v a r i a b l e name=’ count ’/ > </fsmstate> <fsmstate name=’empty ’> <v a r i a b l e name=’ count ’/ > </fsmstate> </state> </actor>
Figure 4.9: Defining the variables that are part of the state of the actor, first allstates describes all the variables that are part of the state, then fsmstate defines for certain states which variables can be ignored in that specific state. the compiler is shown in Figure 4.9, where additionally to the FSM, the actor has a variable that describes its state. The first piece of information (allstates) simply describes the variables that are part of the actor state, while the second part (fsmstate) lists the variables that can be ignored in that specific state.
In addition to the Promela code, these pieces of information serve as the inputs to the following phase of the scheduling, where the goal is to generate schedules for actor partitions. This information is then used to predict the schedules that can be used to schedule the partitions and to partially describe the initial and end states of the partitions.