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

module. Tokens are placed in input port queues atomically, so other source components
cannot interrupt this operation. Note that since each input port of a module M is linked to a
component method, each token that arrives on any input port of M corresponds to a future
invocation of the component(s) in M. When the system is not responding to interrupts or
events on input ports, the system does nothing (i.e., sleeps).
The TinyGALS semantics do not define exactly when the input port is triggered. We
discuss the ramifications of token generation order on the determinacy of the system in
Section 3. Our current implementation processes the tokens in the order that they are
generated as defined by the hardware clock. Tokens generated at the same logical time
are ordered according to the global ordering of module input ports, which we discuss next.
The runtime system maintains a global event queue which keeps track of the tokens in
all module input port queues in the system. Currently, the runtime system activates the
modules corresponding to the tokens in the global event queue using FIFO scheduling.
More sophisticated scheduling algorithms can be added, such as ones that take care of
timing and energy concerns.
In the previous section, we discussed limitations on the configuration of links between
components within a module. Connections between modules are much less restrictive.
Cycles are allowed between modules. This does not lead to reentrancy problems because
the queue on a module input port acts as a delay in the loop. Module output ports may be
connected to one or more module input ports, and module input ports may be connected
to one or more module output ports. The single-output-multiple-input connection acts as
a fork. For example, in Figure 10, every token produced by A_out will be duplicated
and trigger both B_in and C_in. Tokens that are produced at the same “time”, as in the
previous example, are processed with respect to the global input port ordering. Input ports
are first ordered by module order, as they appear in the application configuration file, then in
the order in which they are declared in the module configuration file. The multiple-output-
single-input connection has a merge semantics, such that tokens from multiple sources are
merged into a single stream in the order that the tokens are produced. This type of merge
does not introduce any additional sources of nondeterminacy. See Section 3 for a discussion
20