A State-Based Programming Model for Wireless Sensor Networks

58 Chapter 3. Programming and Runtime Environments
or to form an application. Each component interface defines the tasks, events,
and commands it exports for use by other components. Each component has a
component frame, which constitutes the component’s context, in which all tasks,
events, and commands execute and which stores its state. Components may
be considered objects of a static object-oriented language. Components always
exist for the entire duration of a process and cannot be instantiated or deleted
at runtime. The variables within a component frame are static (i.e., they have
global lifetime) and have component scope (i.e., are visible only from with in
the component). However, multiple static instances of a component may exist as
parameterized interfaces. Parameterized interfaces are statically declared as array
of components and are accessed by index or name. The elements of a component
array provide identical interfaces but have individual states. They are used to
model identical resources, such as individual channels of a multi-channel ADC
or individual network buffers in an array of buffers.
TinyOS is inherently event-driven and thus it shares the benefits of eventdriven
systems. As an event-driven system it has only a single context in which
all program code executes. Therefore the implementation of TinyOS avoids
context-switching overhead. All components share a single runtime stack while
component frames are statically allocated, like global variables. As a deviation
from the basic event-driven model, TinyOS has a two-level scheduling hierarchy
which allows programmers to program interrupt service routines similar to
event handlers using the TinyOS event abstraction. In most other event-driven
systems, interrupts are typically hidden from the programmer and are handled
within the drivers. IO data is typically buffered in the drivers and asynchronous
events are used to communicate their availability to user code. In TinyOS, on
the contrary, interrupts are not hidden from the programmer. This has been a
conscious design decision. It allows to implement time critical operations within
user code and provides greater flexibility for IO-data handling.
However, this approach has a severe drawback. TinyOS events may interrupt
tasks and other events at any time. Thus TinyOS requires programmers to explicitly
synchronize access to variables that are shared within tasks and events
(or within multiple events) in order to avoid data races. TinyOS has many of
the synchronization issues of preemptive multi-tasking, which we consider one
of the main drawback of TinyOS. In oder to support the programmer with synchronization,
more recent versions of nesC have an atomic statement to enforce
atomic operation by disabling interrupt handling. Also, the nesC compiler has
some logic to warn about potential data races. However, it cannot detect all
race conditions and produces a high number of false positives. A code analysis
of TinyOS (see [45]) and its applications has revealed that the code had many
data races before race detection was implemented. In one example with race
detection in place, 156 variables were found to have (possibly multiple) race
conditions, 53 of which were false positives (i.e., about 30%).
The high number of actual race conditions in the TinyOS show that interruptible
code is very hard to understand and manage and thus highly error prone.
Even though the compiler in the recent version now warns about potential data
races, it does not provide hints on how to resolve the conflicts. Conflict resolution
is still left to programmers. The high rate of false positives (about 30%) may
leave programmers in doubt whether they deal with an actual conflict or a false