A State-Based Programming Model for Wireless Sensor Networks

5.7. Summary 97
A
D
E
e
e
B
C
F
e
G
(a)
J
H
e
K
source constellation
(initial state)
Root
A C
D F
H
Root(A(D)|C(F|H))
Root
event e B
C
(b)
target consteallation
(after occurrence of e)
G J
K
Root(B|C(G|J(K)))
Figure 5.12: Determining the transitions to fire in a state machine step. The state
machine depicted in (a) starts in its the initial constellation and e is
the next event from the queue. Transitions originating in A, F , and
H are selected for firing. The transition from D is skipped as transitions
higher in the hierarchy take precedence. In a non-concurrent
state machine at most one transition can fire. If multiple transitions
fire, they can do so in any order.
state and their values are retained during the transition, rather then deleting the
variables and creating new instances.
Note that on a particular hierarchy level, a non-concurrent state machine can
only assume one state at a time. Hence, only the variables of this current state
are active. Variables of mutually exclusive states on the same level can then
be allocated to overlapping memory regions in order to optimize memory consumption
(see Sect. 6.1.1).
By embedding a set of parallel machines into a superstate, actions in different
parallel state machines may access a variable of the superstate concurrently
during the same state machine step at the same discrete time. This is no problem
as long as there is at most one concurrent write access. If there are multiple
concurrent write accesses, these accesses may have to be synchronized in some
way. Due to the run-to-completion semantics of actions, a single write access
will always completely execute before the next write access can occur. However,
the order in which write accesses are executed (in the real-time model) is
arbitrary and may lead to race conditions. Write synchronization is up to the
programmer.
5.7 Summary
In this chapter we have informally presented OSM, a programming model for
resource constrained sensor-nodes. OSM is an extension of the event-driven
programming model, adding two main features to the popular programming
model: firstly, an explicit abstraction of program state as well as mechanisms to