A State-Based Programming Model for Wireless Sensor Networks

3.4. Process Models 49
can not rely on any particular order as it depends on the actual implementation
of the event-scheduling mechanism. In actual systems, the execution order of
actions of separate processes is typically arbitrary.
The answer to the second question—how long can actions be delayed?— may
be important when applications have real-time constraints. The answer depends
on the execution times of actions from the different programs running concurrently
and can therefore not be answered easily by any single application developer.
From our experience with the event-driven model it is already hard
to analyze the timing dependencies in a single application without appropriate
real-time mechanisms. In a concurrent execution environment, where no single
application programmer has the entire timing information, timing estimates are
even harder to get by. Therefore, concurrent process models based on events can
decrease the systems reliability. Since almost all application have at least some
moderate real-time constraints, we believe that process concurrency should be
avoided on event-driven sensor nodes.
Note that a question similar to the second (i.e., how long can the invocation
of an action be delayed?) also arises in multi-treading environments. For such
environments the reformulated question is: how much slower can the program
become with multiple threads running concurrently. In multi-treading environments
the execution delay of operations only depend on the own application
code and the number of programs running concurrently, not the contents (i.e.,
the code) of other programs. For example, in the simple round-robin scheduling,
the CPU time is equally divided among threads. If n threads are running, each
thread is allocated to the CPU for the length of a time slice before having to wait
for another n − 1 time slices. Therefore the execution speed is only 1/(n)-th of
a system with only a single program executing. Actual implementations would
be slower since context-switching consumes non-negligible time.
3.4.5 Analysis of Process Models
Mainly because of potentially unresolvable resource conflicts there are several
reliability issues with process concurrency in sensor networks, regardless if its
implementation is based on context-switches or events.
When appropriate mechanisms for inter-process protection are missing,
which is the rule rather than the exception, a single deficient process can jeopardize
the reliability of the entire system. Even without software bugs it is practically
impossible to analyze in advance whether two concurrent processes will
execute correctly. One problem is, that programs compete for resources in ways
that cannot be anticipated by programmers. If one process requires access to
exclusive resources, such as the radio or sensors, they may be locked by another
process. Limited resources, such as memory and CPU time, may be unavailable
in the required quantities. Identifying potential resource conflicts is
very hard and fixing them with alternate control flows is practically infeasible.
To make things worse, programmers of different applications typically cannot
make arrangements on the timing of CPU intense computations and high resource
usage. Therefore there are typically innumerable ways how two processes
can ruin each others assumptions, particularly in the face of slow and
resource-constrained sensor nodes.