SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks CHAPTER 1 INTRODUCTION A typical Wireless Sensor Network (WSN) consists of a large number of small-sized, battery-powered sensor nodes that are limited in battery energy, CPU power, and communication capability. Recently, WSN has witnessed an explosive growth in both academia and industry, attracting a great deal of research attention in the past few years. WSNs are envisioned to support a variety of applications, including military surveillance, habitat monitoring, and infrastructure protection, etc. Being simple in terms of hardware, WSN applications are diverse and demanding. The infrastructural support for such applications in the form of operating systems (OS) is becoming increasingly important. The basic functionalities of an OS include resource abstractions for various hardware devices, interrupt management, task scheduling, concurrency control, and networking support. Numerous applications are built on top of the OS. A sensor networkOS(hereafter, sensorOSfor short) bridges the gap between the hardware simplicity and the application complexity. It plays a central role in providing a flexible environment for building predictable and efficient services. Over the years, we have seen various OSs emerging in the sensor network community. While they address various challenging issues by adopting different approaches in the Dept of CS&E, PESITM 1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 1INTRODUCTION
A typical Wireless Sensor Network (WSN) consists of a large number of small-sized,
battery-powered sensor nodes that are limited in battery energy, CPU power, and communi-
cation capability. Recently, WSN has witnessed an explosive growth in both academia and
industry, attracting a great deal of research attention in the past few years. WSNs are envi-
sioned to support a variety of applications, including military surveillance, habitat monitor-
ing, and infrastructure protection, etc.
Being simple in terms of hardware, WSN applications are diverse and demanding.
The infrastructural support for such applications in the form of operating systems (OS) is be-
coming increasingly important. The basic functionalities of an OS include resource abstrac-
tions for various hardware devices, interrupt management, task scheduling, concurrency con-
trol, and networking support. Numerous applications are built on top of the OS. A sensor net-
workOS(hereafter, sensorOSfor short) bridges the gap between the hardware simplicity and
the application complexity. It plays a central role in providing a flexible
environment for building predictable and efficient services.
Over the years, we have seen various OSs emerging in the sensor network commu-
nity. While they address various challenging issues by adopting different approaches in the
design spectrum, two important issues, i.e., predictability assurance and programming flexi-
bility, are still not well addressed.
Predictability. As sensor nodes are usually deployed in inaccessible areas, operating
in an unattended manner for a long lifetime, system predictability is highly desirable. The OS
should provide mechanisms to ensure the overall system performance. First, the OS should
provide a level of separation between the OS and applications, e.g., the OS should remain re-
sponsive irrespective of the application behaviors. Second, the OS should provide a level of
separation between different tasks, e.g., a critical task should not be blocked indefinitely by
noncritical tasks or locks hold by a group of tasks.
Flexibility. Since WSN applications have diverse requirements, system flexibility to
facilitate application programming is desirable. The OS should provide many choices to meet
requirements of specific application scenarios and programmers’ preference. A hybrid model
combining both event-driven programming and multithreaded programming is highly pre-
ferred. Specific challenges should be addressed to design a hybrid system while retaining
Dept of CS&E, PESITM 1
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
predictability and efficiency at the same time.
Sensor nodes are usually equipped with low-power microcontrollers with stringent re-
source constraints. The OS should optimize CPU utilization and memory consumption for
high efficiency. Moreover, as sensor nodes are usually deployed in hostile environment in a
large scale, the OS should also support efficient network reprogramming to allow updating
the WSN software.
Dept of CS&E, PESITM 2
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 2
DESIGN OF SENSPIRE OS
This section presents the design of SenSpire OS. Fig. 1 gives an overview of SenSpire
OS’s design principles.
Section 2.1 describes the two-phase interrupt servicing scheme and predictable thread
synchronization primitives for achieving system predictability. Section 2.2 details the hybrid
system design which provides a flexible model for both event-driven programming and multi-
threaded programming. Section 2.3 describes the stack sharing technique
and the modular design approach for achieving system efficiency. In addition, to facilitate
programming distributed sensor network applications, we have also designed a networking
stack and a programming language called CSpire. Section 2.4 introduces the networking ab-
straction and Section 2.5 describes the CSpire language for application programming based
on SenSpire OS.
Figure 1: A overview of SenSpire OS's Design Principle
Dept of CS&E, PESITM 3
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.1 Approaches for Predictability
Interrupt handling is very important for tiny embedded systems like sensor nodes. Ex-
isting sensor OSs usually take a single-phase interrupt servicing scheme. For example, in
TinyOS, interrupts are serviced by asynchronous code that is reachable from (i.e., called
from) one Interrupt Service Routine (ISR). While the OS kernel disables the interrupts only
for brief periods of time, it cannot prevent the applications from disabling interrupts, because
this is the only possible way of synchronization between tasks (i.e., synchronous code in
TinyOS) and interrupts (i.e., asynchronous code in TinyOS). Hence the interrupt latency can-
never be bounded without knowing application behaviors. SenSpire OS adopts a two-phase
interrupt servicing scheme, so that the worst-case interrupt latency can be guaranteed.
Thread synchronization is an important issue in preemptive systems. The design and
implementation of synchronization primitives, however, are overlooked in existing sensor
OSs, such as Contiki OS, Mantis OS. Without a careful design, the synchronization of threads
can lead to an indefinite period of priority inversion, during which a high priority thread waits
indefinitely for the completion of low priority threads. In order to address
this issue, SenSpire OS adopts the priority ceiling protocol to avoid unpredictable priority in-
version and the formation of deadlocks.
2.1.1 Two-Phase Interrupt Servicing
We split interrupt servicing in SenSpire OS into two phases, i.e., the top half and the bottom
half. The top half executes at interrupt time and is meant to be short enough to complete all
necessary actions at the time of the interrupt.
Dept of CS&E, PESITM 4
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Figure 2: The sensetask application in tiny OS versus Senspire OS
It perfoms sensitive and critical tasks with all interrupts disabled. In contrast, the bot-
tom half can be deferred to a more suitable point in time to complete servicing of a prior in-
terrupt. It allows top halves to preempt its execution by enabling
interrupts.
Fig. 2 shows the code snippets for the SenseTask application for both TinyOS-1.x and
SenSpire OS (hereafter, we will use T1 to refer to TinyOS-1.x and T2 to refer to TinyOS-2.x
when different TinyOS versions matter).
The code for SenSpire OS is written in CSpire, which will be introduced in Section
2.5. In CSpire, the bh keyword is used to indicate a bottom half while thetaskkeyword is used
to indicate a run-to-completion task (a run-to-completion task cannot block or self-suspend,
e.g., TinyOS tasks are run-tocompletion). In the code for T1, the atomic keyword is used to
protect the shared data by disabling global interrupts. Hence, within the atomic section, the
OS is not responsive toany other interrupts. In contrast, in the code for SenSpire OS, the
ADC completion event is notified in the context of a bottom half, and the critical primitive is
used to protect the shared data. The critical primitive differs from the atomic primitive in that
it only defers the execution of bottom halves. Hence top halves can still be serviced immedi-
ately once interrupts trigger. Note that the critical primitive is used to protect shared data be-
tween tasks and bottom halves. To protect shared data between bottom halves and top halves,
we should use the atomic keyword (which disables all interrupts) instead. In this case, top
halves cannot interrupt the execution of bottom halves. Interrupt latency depends on the
Dept of CS&E, PESITM 5
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
length of time top halves execute and the rate of interrupts. In TinyOS, the interrupt latency
also depends on the atomic section length because the atomic keyword disables all interrupts
from execution. As the atomic keyword is exposed to application programmers, the applica-
tion code does affect the interrupt latency. On the other hand, in SenSpire OS, the critical
keyword disables bottom halves (but not top halves) and top halves can always be serviced ir-
respective of the critical section size. Hence, SenSpire OS achieves a more predictable inter-
rupt latency.
2.1.2 Predictive Thread Synchronization
A number of recent sensor OS’s support preemptive threading to ensure predictable
system performance. Synchronization primitives are important to serialize the access to
shared resources. The design and implementation of existing synchronization mechanisms are
overlooked in prior preemptive threaded sensor OSs. In fact, a direct application of traditional
synchronization primitives can lead to an indefinite period of priority inversion and a low
level of schedulability.
We consider a similar example in (shown in Fig. 3). T1, T2, and T3 are three threads
arranged in descending order of priority with T1 having the highest priority. T1 and T3 share
a data structure protected by a mutex. At time t1, T3 starts execution. At time t2, T3 locks the
mutex and executes its critical section. During the execution of T3’s critical section, T1 pre-
empts T3 at time t3. At time t4, T1 attempts to use the shared data. However, it blocks on the
mutex hold by T3. At the same time, T2 starts execution till time t5.
Dept of CS&E, PESITM 6
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Figure 3: Example of unpredictable periods of priority inversion
In this example, we would expect that T1, being the highest priority thread, will be
blocked no longer than the time for T3 to complete its execution in the critical section, i.e.,
(t6 - t5). However, the duration of blocking is, in fact, (t6 - t5) + (t5 - t4), which is unpre-
dictable because the execution time of T2 (= t5 - t4) and any other pending intermediate
threads can be sufficiently long’
SenSpire OS hence adopts the priority ceiling protocol to address this issue. It works as
follows:
In SenSpire OS, each thread has a static priority and a dynamic priority.
Each shared resource has a static priority ceiling, which equals to the highest static
priority of the thread that uses it. Thanks to the CSpire language, we are able to obtain
the priority ceiling by program code analysis.
The dynamic priority of a thread equals the maximum of its static priority and priority
ceiling of the shared resource it currently uses.
A ready thread can preempt the current thread only when its static priority is higher
than the dynamic priority of the current thread.
It is formally proved in that the priority ceiling protocol reduces the worst-case blocking
time to at most the duration of execution of a single critical section of a lower priority thread.
In addition, it prevents the formation of deadlocks. In the example shown in Fig. 3, if the pri-
ority ceiling protocol is used, at time t4, T3 will continue because it has a higher dynamic pri-
ority than T2’s static priority.
Dept of CS&E, PESITM 7
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.2 Approaches for Flexibility
The debate between threads and events is a very old one. Event-driven systems have
the benefits of high system responsiveness, high performance, and low resource consumption.
On the other hand, multithreaded systems have the benefits of expressiveness and ease of use,
e.g., application programmers can reason about the series of actions taken by a thread in the
familiar way, leading to a natural programming style in which the control flow for a single
thread is apparent.
As a hybrid model combines both event-driven programming and multithreaded pro-
gramming, we therefore favor it to meet diverse application requirements. With a hybrid
model, it means that the application programmer could design parts of the application using
threads, where threads are the appropriate abstraction, and parts of the system using events,
where they are more suitable. It is flexible and gives the best of two worlds: the expressive-
ness of threads and customizability of events. While there exist a number of prior works on
the design of hybrid models, SenSpire OS’s integral design goals distinguish its hybrid sys-
tem design from existing works. The hybrid model of SenSpire OS has the following fea-
tures.
Flexibility and customizability. Existing hybrid approaches, based on legacy code-
base, make tight coupling of two subsystems, e.g., event-biased approaches require the exis-
tence of the event-driven subsystem while threadbiased approaches require the existence of
multithreaded
subsystem. By natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS al-
lows decoupling of two subsystems, hence is more flexible in expressing and
customizing different scheduling policies.
Predictability and real-time performance. Existing approaches such as Protothreads,
TinyThreads, do not support priority preemption. Other approaches, such as TinyMOS, only
provide a limited number of priorities (e.g., limited to five in TinyMOS). SenSpire OS ad-
vances prior work by supporting programmer-assigned priority-based preemption, thus na-
tively supporting longrunning computations without degrading system performance.
Moreover, SenSpire OS supports event preemption, which is important to achieve pre-
dictability in the eventdriven subsystem. In addition, SenSpire OS employs the
priority ceiling protocol to achieve predictable thread synchronization (Section 2.1).
Dept of CS&E, PESITM 8
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Memory efficiency. Existing hybrid systems, such as TOSThreads, TinyMOS, based
on legacy codebase, preclude aggressive resource optimizations in the implementation. In
contrast, by natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS is
able to exploit stack sharing in order to reduce the stack memory consumption.
2.2.1 Hybrid System
Fig. 4 gives an overview of SenSpire OS’s hybrid system. In SenSpire OS, we clas-
sify tasks in two forms: event handler task (event for short) and thread task (thread for short).
Events are handled by the event-driven subsystem and threads are handled by the multi-
threaded subsystem.
Figure 4:SenSpire OS's Hybrid system
Events are scheduled by Event Schedulers (ESs) which in turn are scheduled by the
Kernel Scheduler (KS). SenSpire OS’s event-driven subsystem is different from TinyOS, in
that we can support multiple preemption levels by the use of multiple ESs. Events in different
ESs can preempt one another. In contrast, the TinyOS core has only one preemption level
within the task context. Some critical system events (e.g., packet reception) are executed in
the task context, sharing the same context as other noncritical tasks (e.g., compression).
Therefore, a critical task can be interfered by the execution of other noncritical tasks ahead of
it. The multithreaded subsystem consists of multiple threads which are directly scheduled by
our KS along with ESs. It is different from Mantis OS, in that we do not employ time-sliced
scheduling, instead, preemption occurs when a high priority thread (or ES) is ready or when
the currently running thread calls a blocking I/O or gives up its CPU cycles voluntarily by
Dept of CS&E, PESITM 9
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
calling sleep( ) or yield( ). Hence the number of context switches can be reduced. In SenSpire
OS, the event-driven subsystem takes a higher priority than the multithreaded subsystem be-
cause it is more suitable for time-sensitive operations.
We have introduced the design of SenSpire OS’s thread synchronization primitives in
Section 2.1.2. In the following section, we will describe SenSpire OS’s novel differentiated
kernel scheduling scheme which implements the hybrid model while reduces memory con-
sumption by stack sharing at the same time.
2.2.2 Differentiated Kernel Scheduling
SenSpire OS’s KS differentiates three execution contexts, i.e., ES, the primary thread
(i.e., the system startup context, denoted as T0), and nonprimary threads (denoted as T1...n).
As each ES represents a nonblocking context, they can share a common stack with one of the
blocking context. In SenSpire OS, all ESs share a common stack with the primary thread.
SenSpire OS’s stack sharing technique is inspired by TinyOS fibers [25], in which a system
stack is shared between events and one thread. SenSpire OS extends it by supporting preemp-
tive events and multiple threads. We will further discuss the issue of stack sharing in Section
2.3.1.
Context switches between ESs or between ES and the primary thread do not involve
stack switching. Stack switching is only required when switching between threads or between
ES and nonprimary threads. Note that we still need to switch the register files. Table 1 shows
the actions taken by the KS.
Dept of CS&E, PESITM 10
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Table 1: Differentiated Kernel Scheduling
Note that, events, being run-to-completion, are not allowed to block. This means that events
cannot block on synchronization primitives such as mutexes. In order to achieve synchroniza-
tion between events of different priorities, or events and threads, we need to manually check
for the resource availability in the event, and need to repost the event if the resource is un-
available at the current time.
The KS employs preemptive scheduling in accordance with the priorities of ESs and
threads. The priorities of ESs must be different while the priorities of threads can be the
same. Within the same priority, the KS schedules threads in an FIFO manner. Each ES uses a
nonpreemptive scheduling scheme. Within each ES, events share a common execution
context and are scheduled by a certain nonpreemptive policy (e.g., FIFO, or nonpreemptive
priority based). Hence, to execute an event, two levels of scheduling are involved: first, the
KS schedules the corresponding ES (which the event is assigned to), then the ES schedules
the event to run.
The scheduling system can be viewed as a hierarchy of execution contexts . As shown
in Figure 5, the Kernel Scheduler schedules two ESs and two threads in a prioritypreemption
manner. The ES-NPPS has the highest priority. Thus any event assigned to it can preempt
other tasks. The scheduling policy is Non-Preemptive Priority Scheduling (NPPS). The ES-
FIFO has an intermediate priority. Any event assigned to it can preempt threads, but not
events assigned to ES-NPPS. It schedules events assigned to it in an FIFO manner. Two
threads have the same lowest priority and can be preempted by any events in the system.
They are scheduled by our KS in an FIFO manner.
Dept of CS&E, PESITM 11
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.2.3 Comparison with Prior Work
Fig. 6 compares SenSpire OS’s hybrid model with prior works in the sensor network commu-
nity. In this figure, x-axis represents the thread phase while the y-axis represents the event
phase. Early OSs, such as TinyOS (also SOS, Contiki OS core), only support nonpreemptive
events. Protothreads , built on Contiki OS, supports thread-like programming. However, it
does not maintain thread-independent data, and does not allow preemption. TinyOS fibers,
built on TinyOS, only supports one thread
Figure 5: An Example for Scheduling hierarchy
Figure 6: Comparision of existing hybrid systems
TinyThreads, also built on TinyOS, implements a cooperative thread mechanism. In
the cooperative thread model, a thread must explicitly yield the CPU to other runnable
Dept of CS&E, PESITM 12
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
threads. The problem with cooperative threads is the correctness of the system depends on
application code voluntarily yielding the CPU at specific intervals. If a thread does not relin-
quish the CPU for a long time, then other threads may be unable to make progress. The same