Dynamic Dataflow Modeling in Ptolemy II - Ptolemy Project ...

have a rigorous proof yet that the algorithm satisfies criterion 3. It remains further work.
However, our experience points to that direction and indeed it is a challenge to come up
with a model that can be executed in bounded memory but fails to do so with our
algorithm.
With the way the algorithm is designed, the set of actors that are executed in each basic
iteration is determinate. The reason is that only at the start of each basic iteration are all
actors classified into sets E, D, minimax(D). These sets are not updated in the middle of
one basic iteration. Each set is a function of a model’s state represented by tokens (their
number and values) queued on each channel. By “function” we mean the contents of each
set do not depend on the order in which we examine the status of each actor. The
resulting state after firing a set of actors does not depend on the order in which we fire
each actor in the set. Therefore we can conclude that each basic iteration is well-defined
and determinate. Later on we will show the mechanism to group several basic iterations
into one iteration that is more meaningful.
3.2 Implementation of DDF Domain in Ptolemy II
This section continues with the implementation of a scheduler under the Ptolemy II
framework. In Ptolemy II, each domain has a director which is responsible for controlling
the execution of actors in that domain. In some domains, such as CT, SDF and SR, the
model can be statically analyzed (called compiling a model) to come up with a schedule
before execution starts. That is the job of a scheduler. In other domains such as DE,
firings of actors can only be dynamically scheduled during the execution. For these
domains, there is no (static) scheduler per se and all functionality (including dynamic
30