A State-Based Programming Model for Wireless Sensor Networks

4.2. The Anatomy of Sensor-Node Programs 73
INIT
init_done
NORMAL_OPERATION
SAMPLE
sample_done (n)ack timeout
SEND
wakeup sleep
SLEEP
IDLE
Figure 4.3: The three program phases SAMPLE, SEND, and IDLE are preempted
by the sleep event.
The execution of the target phase of a preemption takes priority over the preempted
phases. Preemption is basically the same as what we have previously
called branching, only that preemption has a number of source phases (rather
then just one). Preemption is can be considered as handling of exceptions. The
phase to which control is transferred to may then be considered the exception
handler.
Specifying preemption in the event-model requires extensive state management.
The difficulty is two-fold: Firstly, on the occurrence of a preempting event,
the programmer must first deinitialize the phases that are to be preempted. Special
care must be taken if preemption is added during the redesign of a sensornode
program. From our experience, proper deinitialization can be easily forgotten.
And secondly, (future) events that are caused by computational operations
performed before the preemption occurred must be actively ignored. For
example, in our example program the (n)ack event is caused by sending a data
sample. If the send operation has completed, but a sleep event is received next
(i.e., before the (n)ack event), the (n)ack event is nevertheless generated by the
OS and thus triggers the associated action. In this action, however, it needs to be
ignored. The code fragment in Prog. 4.4 shows a possible implementation of the
preemption in the event-driven model. The handler of the sleep event (lines 1-
14) implements the preemption. The preempted phases are deinitialized within
the switch statement (lines 3-11). The handler of the nack event first checks the
exceptional case when the program is in the SLEEP state (lines 16). Then the
nack event is ignored. If the program was coming from the SEND phase (which
is the regular case), it behaves as without preemption. Clearly, the complexity of
manual state management in the case of preemption is hard to handle for programmers.
Even this short program is hard to write and even harder to read. To
deduce a programmers intention from the code is next to impossible.
Structuring Program Phases: Phase Hierarchies
In some cases, it is convenient to think of a set of sequentially composed phases
as a single, higher-level program phase. This implies that there is a hierarchy of
phases, where phases higher in the hierarchy (which we call super-phases) are
composed of one or more sub-phases. Our previous example, Fig. 4.3, is such a
case.