The problem of scheduling dynamic dataflow programs is manifold and can be explored from several angles. Starting from a choice between different models of computations, which restricts or enriches the model with extra information, to approaches which try to fit parts of a program in to more static descriptions, and by this, extract static schedules. The approach investigated in this thesis, starts from an expressive model, which is allowed to describe dataflow actors with any behavior. These actors are analyzed and a model describing the behavior of an actor partition, with a limited state space only including scheduling related information, is constructed. Then the state space is analyzed, and static schedules that link some of the reoccurring states of the program are extracted and used to generate a quasi-static scheduler. The problems discussed in this thesis are different aspects of how this analysis is made feasible.
The first thing that is needed to even make a state space analysis of a dataflow program feasible is to reduce the state space to only include the in- formation essential for the scheduling analysis. A CAL program, essentially, is a set of dataflow actors which can be described as state machines with variables, and which are connected by data channels. One of the main points in the thesis is therefore to show how to describe the state space of a program, with the minimal information such that the program
can be scheduled correctly. This property is a central requirement in the
work presented and is therefore discussed throughout the thesis, but mainly in Papers 2 and 4, and in Chapters 3, 4, and 5.
A related issue, which is important for constructing a set of guards for a composition of actors, relates to the set of firing rules that are used by the quasi-static scheduler, and how these can be chosen. The related research problem is how one can show that a set of guards are strong enough to describe the behavior of a partition, and how control values should be modeled in order to choose suitable partitions for composition. This is on a more abstract level discussed in Chapter 3 and with some more details in Paper 4; then in Chapter 5, more concrete examples are given of how this issue can be handled.
With a model that efficiently describes the state space of the program and correctly gives an adequate set of guards that describes the operations of a dataflow program, or part of one, the next problem is to actually extract both the static schedules and a scheduler which describes how the schedules should be fired based on the set of guards provided. The thesis, therefore, also presents a number of strategies that can be used to find static schedules out of the state space of a program partition by using a
model checker. The initial work related to this issue is presented in Paper
1, however, a more in depth discussion is provided in Chapter 5, while some case studies are presented in Chapter 7.
With the composition and partial compile-time scheduling of the actor partitions successfully completed, one would hope that the transformed pro- gram in every sense performs better than the original program where each actor is individually scheduled at run-time. Now, this is unfortunately not simply a software issue, as the processor architecture plays a crucial role in deciding how a composition and a specific schedule impacts on the perfor- mance. For this reason, the thesis contributes with measurements and conclusions regarding how partitioning, scheduling, and composi-
tion affect the performance of a program. Measurements are mainly
presented in Papers 3 and 5, while Chapter 6 provides a more general dis- cussion of this topic.
The work done related to this thesis shows that this type of methods can be used to schedule CAL actors for composition. However, to enable more automatized and successful scheduling of CAL program, some improvements regarding specification of programs could be useful for a future tool set to allow easier verification of properties related to scheduling, but potentially also others. The case studies in Chapter 7 highlights some constructs that make the scheduling difficult, some possible solutions on how to implement dataflow programs or how specifications could be added to a program is discussed in Chapter 8.
Orcc C Backend Promela Backend Scheduling Tool RVC-CAL Prog Missing Schedules C code Scheduler Promela Code Input Sequences Actor Schdules Merger Partitions
Figure 1.1: The artifacts produced for the scheduling task and how these connect to the existing tool chain (gray).
1.4.1 Constructed Artifacts
In order to evaluate the proposed approach and to measure the impact this kind of composition and scheduling has on a dataflow program when it is mapped on to different platforms, it is necessary to build a number of software artifacts that can be used for this purpose. The scheduling approach is implemented as part of a existing compiler infrastructure and some additional external tools, which produce interchange artifacts that describe different aspects of the dataflow program. Figure 1.1 illustrates the main software components and the information that is passed between these. A central part of the tool chain is the Orcc compiler which is both used to generate the representation of the program that is used in the scheduling as well as to finally generate the executable program, based on the information generated by the scheduling tool, to a language such as C, that can be compiled to the target platform.
The approach is described in more detail in the following chapters, how- ever, to put these in a context, some of the high level ideas and key artifacts should be introduced.
Scheduling Tool The scheduling tool, which consists of a model checker
and a wrapping software that specifies the model checking tasks and analyses the model checking result. This software uses information generated from the dataflow program description and defines a set of schedules for the model checker to search for. The scheduling is a iterative task where one found schedule may introduce new schedules to search for, this is illustrated by the feedback loop of the scheduling tool in Figure 1.1. This part of the
scheduling approach is mainly described in Chapter 5.
Partition The set of actors that are to be composed and thereby ana-
lyzed for scheduling is called a partition. A partition may correspond to the whole dataflow program but usually partitions are chosen, by the designer, to minimize the scheduling overhead by grouping together actors with re- lated behavior, and to improve run-time performance by choosing partition sizes that fit the target platform. Partitioning is only described in this thesis from the point of view of correctness, where correctness means that a model describing the scheduling of a partition must include all the necessary in- formation, while the performance aspect is left for an external design space exploration. The required properties of a partition is discussed in Chapter 3, which presents the different types of dynamic behavior a partition of actors can have.
Schedules The task of the scheduling framework is to produces static
schedules, that is, sequences of firings that, once chosen for execution, the whole schedule can be guaranteed to run to completion without the need for evaluating guard expressions. When several schedules are need to describe the behavior of a partition, the choice of schedule is performed by a scheduler at run-time. The scheduler produces, the schedules and the firing rules for these, is then the artifact that is the end result of the scheduling tool and is used by the compiler to merge actors before the code is generated for the target platform. The construction of a set of static schedules for a partition together with a scheduler that corresponds to the firing rules of the schedules, is mainly discussed in Chapter 5.
To construct and initialize the model checker for one scheduling task a few pieces of information, either automatically generated from the dataflow program or provided by the developer, is need.
Promela Code The behavior of the dataflow program is translated to the
language used by the model checker, in this case Promela. For this purpose a backend producing Promela code is constructed for the Orcc compiler. The generation of the Promela code not as such interesting in this context, and is only briefly described in Chapter 5 and Paper 1, instead finding the relevant information to generate code from is more relevant. An addition to generating the Promela code, the backed runs a set of analysis passes which are used to simplify the program description to only include scheduling information as well as producing additional information which is used by the scheduling tool, this involves information regarding static schedules and their corresponding input sequences of individual actors.
Actor Schedules Simplifying of the individual actors to only include in- put dependent firing rules, while firing sequences that can be resolved from the program text of the actor are described as static schedules, gives a good staring point for the actual scheduling task. Generating a set of static sched- ules that describe the possible firing sequences of the actor, gives a predic- tions of what the static schedules, of a partition, that are to be searched for by the model checker should look like. Similarly, it also gives the data rates and the needed input sequences that are consumed by the corresponding schedules.
Input Sequences A final artifact that is produced as an input for the
model checking task, is the set of input sequences an actor accepts. These input sequences correspond to the per actor static schedules described above, and describe the number of data tokens a schedule consumes and, if it can be resolved, the value of a control token that enables the schedule. This information is used to initialize the model checking tasks as well as to de- cide when a schedule has finished based on the number of tokens it has consumed. The construction of the actor schedules and the corresponding input sequences is discussed in Chapter 4.