The actual scheduling is a composition of the actor state machines which in this case are represented by Promela processes. The composed scheduler describes a set of reoccurring program states which are linked by a set of schedules, representing processing the possible inputs of the program. This
means that the composed scheduler typically is less general than a parallel composition of the actors, where the behavior of the program would be exactly the same as in the original program. The new scheduler will require more data to be available before the processing can start, however, for a specific input, the output is guaranteed to be the same as for the original program, but slightly delayed.
The practical scheduling consists of identifying the schedules to search for, instrumenting the Promela program to correspond to the state where the schedule starts, describe where the schedule should end, and analyze the model checker outputs.
Identify Schedules The schedules to search for correspond to the guards
which have been verified to cover the possible input sequences for the par- tition. When the guards are the guards that checks properties of the inputs of one actor in the partition, the scheduler of the partition can be assumed to resemble the scheduler of this actor. For this reason, one of the actors of the partition that has the guards that completely covers the inputs is chosen as the partition leader and is used to generate the initial scheduler for the partition.
The initial set of schedules will for this reason correspond the actor level scheduler, of the leader actor, as described in the previous chapter. A schedule then corresponds to the sequence of actions that can fire in that actor without evaluating any guards, furthermore, the schedule of the partition also includes the actions that fires as a consequence of the action sequence that fired in the leader actor. The state machine of the generated scheduler corresponds to the states of the FSM of this actor where an input dependent condition must be evaluated in order to choose the next action to fire.
The description of the schedules to be found consists of three parts, the FSM state of the leader actor, the actual state including FIFOs, variables and FSM states of the whole partition, and the action from which the guard that enables the schedule is taken. The starting point of the scheduling may look like the following example.
[0] i n t e r : r e a d - > r e a d : ( s0 - > ?) [1] i n t r a : r e a d - > r e a d : ( s0 - > ?) [2] o t h e r : r e a d - > r e a d : ( s0 - > ?) [3] s t a r t : r e a d - > r e a d : ( s0 - > ?)
These four specifications represent four schedules, which, at least, are needed for scheduling the intra coding part of a MPEG-4 decoder. Each schedule is represented by the enabling action, the start and end state of the leader action and finally the start and end state of the partition. In this
Algorithm 5.1 Scheduling Process – Constructing the composed FSM by finding schedules corresponding to the schedules of the leader actor; when a new state is found, the schedules starting at the corresponding FSM state of the leader actor (σleader≈ σnew) are also searched for.
1: Σpartition:={σinit} . Concrete states
2: Sl:={(σstart, σend), ...} . Schedules of the leader actor
3: Sm := σinit× {k | k ∈ Sl∧ dom(k) ≈ σinit} . Schedules to be found
4: while Sm6= ∅ do
5: s :∈ Sm
6: (σn, t) := f indschedule(s) . Run model checker
7: Sm:= Sm\ s
8: if σn∈ Σ/ partition then . New state found
9: Σpartition:= Σpartition∪ {σn}
10: Sm := Sm∪ σn× {k | k ∈ Sl∧ dom(k) ≈ σn}
11: end if
12: end while
case, the action, or the guard of the action, checks if the input is an intra or inter block, if the input is coded without intra prediction, or if it is the beginning of a new frame. The next field states that the schedule should start and end at a state where the leader actor is in the state read, and finally the last field states that the schedule starts at a state s0 and ends at a yet unknown state. The difference between the states read and s0 is that the first indicates any state where the leader actor is in its FSM state called read while the second state describes the full state including state variables and the FSM state of each of the actors.
The last part of the scheduling description is actually the most interest- ing. The scheduling step is completed when each of the question marks has been replaced with a concrete state. When a schedule is found, if the sched- ule ends in an already known state, the question mark is simply replaced with this state, if the state is not known from before, a new state is added to the scheduler. A new state means that it is necessary to find schedules leaving that state too. As an example, when a schedule is found for the intra schedule in the previous description, it does not correspond to the s0 state, which means that a new state, s1, is added to the scheduling description. The new schedules needed from s1 are those representing the actions that may be enabled in the state read of the leader actor as s1 corresponds to the state read of the leader actor according to the specification. The scheduling process is described in Algorithm 5.1, which shows how the schedules of the leader actor and the initial state of the partition are used to produce the appropriate scheduling tasks for the model checker to find.
like the following. Here the scheduler takes into account every input se- quence that can occur at the same time as it considers the different states the partition may end up in after processing the different input sequences.
[0] i n t e r : r e a d - > r e a d : ( s0 - > s1 ) [1] i n t r a : r e a d - > r e a d : ( s0 - > s1 ) [2] o t h e r : r e a d - > r e a d : ( s0 - > s0 ) [3] s t a r t : r e a d - > r e a d : ( s0 - > s0 ) [4] i n t e r : r e a d - > r e a d : ( s1 - > s1 ) [5] i n t r a : r e a d - > r e a d : ( s1 - > s1 ) [6] o t h e r : r e a d - > r e a d : ( s1 - > s0 ) [7] s t a r t : r e a d - > r e a d : ( s1 - > s0 )
In practice, the concrete state of the partition must be used to instrument the model checker and be compared to the states the model checker finds when it performs the state space analysis.
Instrumentation of Model Checker Describing the state of the pro-
gram partition as well as configuring the partition to a specific state is es- sential for constructing the schedules for the partition. Three operations are needed for the model checking. First, we need to describe the initial state of the program such that the scheduling information is exactly described while data properties are skipped. Second, we need to read the exact state of the program when a schedule has been found. And, third, we need to be able to setup the program to each of the states that has been identified.
A state of the Promela program can be found either by simulating the program and reading the end state or by running model checking and reading the end state of the checking in the case a state that was specified to be searched for was found. To find the initial state of the program, a simulation run where no action is allowed to fire is run, as variables not related to scheduling already has been removed from the model, capturing the state variables of the partition gives the exact initial state of the Promela program. Then from this forward, the program is always initialized with either the initial state or one of the other found end states.
i n i t { # i n c l u d e " s t a t e . pml " a t o m i c { run a c t o r 1 (); run a c t o r 2 (); ... } } # i n c l u d e " t m p _ l t l _ e x p r . pml "
Search for Schedules The last piece of the model checking puzzle is the description of the state to look for. Now, model checkers are typically meant for verifying correctness of programs, thus correctness properties that should hold for the program are described and errors are reported by the model checker when a violation is found. Typically an error state or a sequence of states that should never occur are described with linear-time temporal logic which enables reasoning about the order in which things happen.
In the search for schedules, we are interested in finding specific states in the program state space and the sequence of action firings that leads to that state from the state to which the model checker was initialized. To make the model checker to search for a specific state and report that the state is reachable providing the path (the trace) to this state, the state needs to be described as an unwanted error state. This kind of (miss-) using the model checker is needed when a general model checker that is designed to verify correctness and not schedule existence is used for this purpose.
The state to be found can simply be described as a linear-time temporal
logic formula, as is shown in Formula 5.1, which simply says that for every
state (the square), there should not be a state where the program has made
progress, by firing at-least one action, and where the FSM of actor1 is in
the state named state1, and the data of the FIFOs of the partition has been consumed. What is actually described here is that, first of all, a schedule requires that something has been done, else the schedule is useless. Second, a partial specification of the state to be found is described typically describing how one of the actors should be run during this schedule, and last, some description of how the other actors have synchronized with the tokens that has been produced by getting to the specified state.
ltl ! (hasP rogress∧ F SMactor1== state1∧ emptyBuffers) (5.1)
The spin model checker generates an automaton, based on this formula, that is executed in lock-steps with the program that is model checked. The automaton describes a sequence that should never occur and it is an error when the automaton terminates; the generated trace to the error can then be used in combination with the simulator to run the program according to the schedule that ends up in the specified state [72]. The simulator can then be instrumented to generate the information that is needed to both get the schedule and the state that is needed to decide on how the new scheduler needs to be updated to correspond to the information gained from running the model checker.
Model Checking Results The output from the model checker, when the
state and the complete state description of the state that corresponded to the described state. The sequence directly corresponds to a schedule while the state needs to be compared to the other states already found and decisions about how to update the scheduler are made from this comparison. The complete state description is a listing of the state variables that are used in scheduling, the contents of the FIFOs, and the FSM states represented by variables in the Promela representation.
// s0
v a r _ a c t o r 1 _ v a r 1 = VAL ; v a r _ a c t o r 1 _ v a r 2 = VAL ; f s m _ a c t o r 1 = s t a t e 1 ;
The resulting state, after the schedule search, is compared to already reached states to find a minimal number of states that can describe the new scheduler. The state variables that are used to describe the state are only those that are reachable from a guard in the dependency graph, it would else not be possible to generate a neat scheduler if also data variables would be included as the number of states would become enormous. To further improve the precision of the state description, a state variable filter that describes, for each FSM state, which state variables are relevant, is used. This filter is based on the analysis described in the previous chapter (in Section 4.5), and it simply keeps track of, for each state, whether a variable will be overwritten before being used in a guard expression. In some cases, as will be demonstrated in Case Study V in Chapter7, this can significantly reduce the number of states in the generated scheduler.
The reached states are used when the Promela representation is instru- mented for a scheduling run. The state that is included in the model looks like the example below, containing the assignment of the state variables, FSMs, and pushing the relevant inputs to the input channels of the parti- tion. // s0 s t a t e v a r _ a c t o r 1 _ v a r 1 = VAL ; v a r _ a c t o r 1 _ v a r 2 = VAL ; f s m _ a c t o r 1 = s t a t e 1 ; // i n p u t s c h a n _ a c t o r 1 _ p o r t 1 ! C N T L _ V A L 1 ; c h a n _ a c t o r 1 _ p o r t 2 !0; ...
This completes the scheduling cycle. The model checking gives a more and more exact description of the scheduler needed; this in turn is used as input to the model checker. Finally when each reached state has an outgoing
transition (schedule) for each type of input that is accepted in that state, the scheduling is completed.