21.08.2013 Views

A State-Based Programming Model for Wireless Sensor Networks

A State-Based Programming Model for Wireless Sensor Networks

A State-Based Programming Model for Wireless Sensor Networks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

94 Chapter 5. The Object-<strong>State</strong> <strong>Model</strong><br />

the entry actions of B and then be evaluated in the guard, selecting the actual<br />

initial state. This is possible since the entry actions of a superstate are always<br />

executed be<strong>for</strong>e the initial-state condition is evaluated.<br />

A<br />

g<br />

C<br />

e<br />

f<br />

e<br />

f<br />

inB1()<br />

inB2()<br />

inB3()<br />

inB4()<br />

B<br />

var int a<br />

[a=1]<br />

[else]<br />

Figure 5.10: Conditional entrance to the substates D and E of B, depending on<br />

guards over the state variable a. The state variable a can be set in<br />

the entry actions of B, <strong>for</strong> example, depending on which transition<br />

was taken.<br />

5.5.3 Substate Preemption<br />

When a transition fires, it ends the lifetime of its source state. We say the transition<br />

terminates the source state normally. If the source state of a transition is<br />

a superstate, the transition also preempts its substates (i.e., the embedded state<br />

machine). Then we say the transition preempts the source state’s substates. <strong>State</strong>s<br />

can only be left either through normal termination or through preemption. Substates<br />

are preempted level-by-level, starting from the bottom-most state in the<br />

hierarchy. A substate cannot prevent its superstate from being left (and thus<br />

itself from being preempted).<br />

If a state is preempted, its exit actions do not fire as during normal termination.<br />

In order to allow the preempted state to react to the termination or preemption<br />

of its superstate (and thus its own preemption), preemption actions are<br />

introduced. Preemption actions are useful, <strong>for</strong> example, to release resources that<br />

where initialized in the preempted states’ entry actions. Each state can have a<br />

single preemption action. This preemption action is invoked as the state is preempted.<br />

Preemption actions are invoked in the order in which their states are<br />

preempted, that is, from the bottom of the hierarchy to its top. The substates’<br />

preemption actions are invoked be<strong>for</strong>e the exit action of their superstate. Preemption<br />

actions of parallel states are executed in any order.<br />

The scope of the preemption action is the to-be-preempted substate. That is, a<br />

preemption action can access all state variables its state be<strong>for</strong>e it is actually being<br />

preempted plus all state variables of (direct and indirect) superstates. Note<br />

however, that a transition terminating a state directly does not trigger that state’s<br />

preemption action—any required operations can be per<strong>for</strong>med in the regular<br />

exit action. In a preemption action, there is no means to determine any in<strong>for</strong>mation<br />

of the actual transition causing the preemption, such as its trigger and its<br />

source state.<br />

D<br />

E

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!