A State-Based Programming Model for Wireless Sensor Networks

3.4. Process Models 47
tive measures, special mechanisms for inter-process communication exist, like
shared memory, message passing, and semaphores.
The main objectives of process concurrency in general-purpose operating systems
is to optimize processor utilization and usability (cf. [108]). While one
process is waiting for an input or output operation to commence (e.g., writing
a file to secondary storage or waiting for user input), another process can continue
its execution. Therefore some process is always running. From a user perspective,
process concurrency can increase the systems usefulness and reactivity.
Running several programs in parallel allows to share the processing power of a
single computer among multiple users. To each of the users it appears as if they
had their own (albeit slower) computer exclusively to them. Also, a single user
running several applications can switch back and forth between them without
having to terminate them.
Context-switching sensor-node processes. In order to avoid the resource overhead
induced by two layers of scheduling, context-switsched sensor-node operating
systems typically only provide a single level of scheduling on the basis of
threads. That is, threads are the only scheduled entity. This does not mean,
however, that multi-threaded sensor-node operating systems cannot provide
process concurrency. If they do, the threads of distinct processes are contextswitched,
thereby also switching processes. Processes then consist of a collections
of threads, which are indistinguishable from the threads of other processes.
The notion of a process is entirely logical, denoting all threads belonging to a
program. In simple implementations a fine-grained control mechanism over the
CPU time assigned to processes is missing; a process with more threads may receive
more CPU time. To dynamically create a new process, the binary image of
the program (consisting of a collection of threads) is loaded and all of its threads
are instantiated.
Threads or tasks? In the face of a single level of context switching, the question
my arise, why we consider the context-switched entities of sensor-node
system software to be threads rather then processes. This seems to be a rather
arbitrary, if not an unusual view, because in the history of modern operatingsystem
development, support for concurrent processes (e.g., multi-tasking) was
introduced well before concurrency within individual processes, as provided by
multi-threading (cf. [27]). In fact, multi-threading was long missing in generalpurpose
operating systems.
Though threads and tasks are similar in several respects, they have been developed
for different reasons and serve different objectives. While multi-tasking
aims more at the user of the computer system, multi-threading is mainly an abstraction
to aid programmers. In sensor networks, concurrency is mainly considered
a tool for specifying reactive programs while supporting multiple processes
or even multiple users is considered less important. Also, the context-switched
entities in wireless sensor networks have much more in common with threads
than processes, because of the way they share resources. Most of the measures
to protect distinct processes found in traditional multi-tasking systems are not
(and cannot be) implemented in sensor networks. Because of these reasons, the
term task has become widely accepted in sensor-network literature to denote
context-switched entities.