A State-Based Programming Model for Wireless Sensor Networks

66 Chapter 4. Event-driven Programming in Practice
Program 4.2: General pattern to implement context sensitive actions.
1 typedef enum {INIT, A, B, ... } state_t;
2 state_t state = INIT; // initial state
3
4 void event_handler_x {
5 switch( state ) {
6 case INIT:
7 // handle event_x in state INIT
8 state = ...; // set new state
9 break;
10 case A:
11 // handle event_x in state A
12 state = ...; // set new state
13 break;
14 case B:
15 // handle event_x in state B
16 state = ...; // set new state
17 break;
18 default:
19 // ...
20 }
21 }
22 void event_handler_y {
23 // ...
24 }
when the programmer was not expecting them (e.g., duplicated network messages
or events generated by another action), however, will trigger their associated
operation regardless. To enforce the correct behavior, programmers need to
manage contex information and need to code the program’s flow control explicitly.
In the event-driven model the reaction to an event cannot be specified with
respect to such context information. Instead an event always triggers its single
associated action. The event model does not provide any means against restarting
of such phases anew. (In fact, there is not even an abstraction to indicate
which parts of the code implement a single logical operation.) Special care must
be taken by programmers not to accidentally restart a cascade of actions. In oder
to be able to detect such errors, a defensive programmer would set a flag at the
beginning of the logical operation and check it in every action to trigger exception
handling. For the example Program 4.1, this could be achieved by checking
whether every invocation of init_remote_average()) has been followed by
a call to timeout_hdl() or otherwise ignore the invocation. The following additional
code implements a possible solution when inserted after line 5 of the
example:
if( sampling_active == TRUE ) {
return; // error, ignore
}