Design and Implementation of TinyGALS: A Programming Model for ...

Application def.
include modules{
A;
B;
};
globals{
statevar;
};
statevar A_param
statevar B_param
...
// Module def. for A
include components{
A1;
};
parameters{
int A_param;
};
...
Figure 11: Defining and accessing TinyGUYS variables.
// Component impl. for A1
...
void fire() {
...
int a;
a=PARAMETER_GET(A_param);
a++;
PARAMETER_PUT(A_param)(a);
...
};
variable. TinyGUYS variables are updated atomically by the scheduler only when it is safe
(e.g., after one module finishes and before the scheduler triggers the next module). One
can think of this as a way of formalizing race conditions. We discuss how to eliminate race
conditions in Section 3.1.
TinyGUYS have global names (GLOBALSA) that are mapped to the parameters (PARAMET ERSM)
of each module M. If a component C uses a parameter, it must declare it as an external
variable (XC). Figure 11 shows some sample code for defining and accessing TinyGUYS
variables. The left-hand column of Figure 11 shows an application definition, which con-
tains a list of global variable names, as well as a list of mappings from global names to local
names. These local variables must be defined as parameters of the modules; this is shown
in the center column of Figure 11. Local variables can be accessed within a component
by using special constructs, PARAMETER_GET and PARAMETER_PUT, as shown in the
right-hand column of Figure 11. This style of declaration, in which the types of the global
variables must be declared at the module level, is slightly awkward. This means that the
types must be declared for each module that uses the global variables. It also increases the
fragility of the component code, since the components do not know the types of the global
variables. In the future, we plan to improve this mechanism to use scoping, perhaps in a
way similar to scoped parameters in Ptolemy II [11]. We could also use the Ptolemy II type
system to improve the way in which types must be declared in TinyGALS.
22