Y-threads: Supporting concurrency in wireless sensor networks
Page 1
Y-threads: Supporting concurrency in wireless sensor networks
P. Gibbons et al. (Eds.): DCOSS 2006, LNCS 4026, pp. 169
–
184, 2006.
' Springer-Verlag Berlin Heidelberg 2006
Y-Threads: Supporting Concurrency
in Wireless Sensor Networks
Christopher Nitta, Raju Pandey, and Yann Ramin
Department of Computer Science
University of California, Davis
Davis, CA 95616
{nitta, pandey, ramin}@cs.ucdavis.edu
Abstract. Resource constrained systems often are programmed using an event-
based model. Many applications do not lend themselves well to an event-based
approach, but preemptive multithreading pre-allocates resources that cannot be
used even while not in use by the owning thread. In this paper, we propose a
hybrid approach called Y-Threads. Y-Threads provide separate small stacks for
blocking portions of applications, while allowing for shared stacks for non-
blocking computations. We have implemented Y-Threads on Mica and Telos
wireless sensor network platforms. The results show that Y-Threads provide a
preemptive multithreaded programming model with resource utilization closer
to an event-based approach. In addition, relatively large memory buffers can be
allocated for temporary use with less overhead than conventional dynamic
memory allocation methods.
Keywords: Stack sharing, Multi-threading, Concurrency.
1 Introduction
Wireless Sensor Network (WSN) systems are inherently concurrent. Support for
concurrency is needed in all layers of the WSN software stack. At the operating
system level, hardware interrupts, low level I/O and sensor events are asynchronous.
At the middleware level, specific services (such as time synchronization [1][2] and
code distribution[3][4][5]) are highly concurrent in nature, and exist independently
from other activities. For instance, most code distribution protocols have several
concurrent activities: one may actively maintain a code distribution tree by
periodically collecting neighbor information, while the other may cache and distribute
code along the distribution tree. At the application level, programs may define both
node-level (e.g., collect data) and group level activities (e.g., aggregate data), each
occurring concurrently.
Concurrency exists not only at many different levels, but also in many different
forms: rapid responses to specific events are easily represented using events and event
handlers; concurrency among middleware services are better expressed using long
running threads (LRT); concurrency and group concurrent activities are better defined
using a combination of threads and atomic computations; and higher level system
software abstractions (such as virtual machines and middleware) can be implemented
–
184, 2006.
' Springer-Verlag Berlin Heidelberg 2006
Y-Threads: Supporting Concurrency
in Wireless Sensor Networks
Christopher Nitta, Raju Pandey, and Yann Ramin
Department of Computer Science
University of California, Davis
Davis, CA 95616
{nitta, pandey, ramin}@cs.ucdavis.edu
Abstract. Resource constrained systems often are programmed using an event-
based model. Many applications do not lend themselves well to an event-based
approach, but preemptive multithreading pre-allocates resources that cannot be
used even while not in use by the owning thread. In this paper, we propose a
hybrid approach called Y-Threads. Y-Threads provide separate small stacks for
blocking portions of applications, while allowing for shared stacks for non-
blocking computations. We have implemented Y-Threads on Mica and Telos
wireless sensor network platforms. The results show that Y-Threads provide a
preemptive multithreaded programming model with resource utilization closer
to an event-based approach. In addition, relatively large memory buffers can be
allocated for temporary use with less overhead than conventional dynamic
memory allocation methods.
Keywords: Stack sharing, Multi-threading, Concurrency.
1 Introduction
Wireless Sensor Network (WSN) systems are inherently concurrent. Support for
concurrency is needed in all layers of the WSN software stack. At the operating
system level, hardware interrupts, low level I/O and sensor events are asynchronous.
At the middleware level, specific services (such as time synchronization [1][2] and
code distribution[3][4][5]) are highly concurrent in nature, and exist independently
from other activities. For instance, most code distribution protocols have several
concurrent activities: one may actively maintain a code distribution tree by
periodically collecting neighbor information, while the other may cache and distribute
code along the distribution tree. At the application level, programs may define both
node-level (e.g., collect data) and group level activities (e.g., aggregate data), each
occurring concurrently.
Concurrency exists not only at many different levels, but also in many different
forms: rapid responses to specific events are easily represented using events and event
handlers; concurrency among middleware services are better expressed using long
running threads (LRT); concurrency and group concurrent activities are better defined
using a combination of threads and atomic computations; and higher level system
software abstractions (such as virtual machines and middleware) can be implemented
Page 2
170 C. Nitta, R. Pandey, and Y. Ramin
easier using a threading mechanism. We have examined these concurrency models
and believe there is a disconnect between the two main models.
WSN Operating Systems work with limited resources, RAM being the primary
limitation. The limited RAM drives many embedded system designers to use an
event-based programming model as in TinyOS[6] and SOS[7]. Though [8] shows that
event-based and thread-based approaches can be interchanged, many applications do
not lend themselves well to an event-based approach, especially those where true
CPU concurrency is needed[9][10]. Often embedded system tasks run a cycle of work
and waiting. Blocking is done at the highest level, computation is executed to
completion and waiting occurs again. Preemptive multithreading pre-allocates RAM
that cannot be used even while not in use by the owning thread. What is needed is a
concurrency model that balances the programming needs through a preemptive
threading model and at the same time meets the resource constraints of sensing
devices.
We introduce a hybrid approach called Y-Threads. Y-Threads are preemptive
multithreads with small thread stacks. The majority of work in Y-Threads is done by
non-blocking routines that execute on a separate common stack. By separating the
execution stacks of control and computational behavior, Y-Threads can support
preemptive threading model with better memory utilization than preemptive
multithreading alone.
We have implemented Y-Threads on several WSN platforms. Experimental results
show that a Y-Thread version of a time synchronization application only increased
energy consumption by 0.12% over the original purely multithreaded version. In
addition the worst-case RAM requirement for the Y-Thread implementation was
reduced by 16.5%. Experiments also show that Y-Thread implementations of a flash
modification routine are more processing efficient than versions that dynamically
allocate memory.
The rest of this paper is structured as follows. Section 2 discusses the motivation,
programming model, and implementation of Y-Threads. Experimental test
applications and results are described in Section 3. Section 4 discusses the existing
concurrency models more in depth. Section 5 discusses the possibilities of future
work on Y-Threads. We conclude in Section 6.
2 Y-Threads
Y-Threads are preemptive threads and are well suited to capture the reactive nature of
many WSN programs. It is based on the insight that many WSN applications block,
waiting for specific events to occur, that has motivated the development of Y-
Threads. As events occur, they react by performing atomic computations, changing
their state, and returning to the wait mode. Behavior of many such applications can be
captured in terms of two sets of behavior: the first is a control behavior that is state-
based and that guides the application through different state transitions as different
events occur. The second are the different computational behaviors that occur during
various state transitions.
For instance, consider the time synchronization code sample shown in Fig. 1. The
control behavior is defined in the while loop: the application blocks while waiting for
easier using a threading mechanism. We have examined these concurrency models
and believe there is a disconnect between the two main models.
WSN Operating Systems work with limited resources, RAM being the primary
limitation. The limited RAM drives many embedded system designers to use an
event-based programming model as in TinyOS[6] and SOS[7]. Though [8] shows that
event-based and thread-based approaches can be interchanged, many applications do
not lend themselves well to an event-based approach, especially those where true
CPU concurrency is needed[9][10]. Often embedded system tasks run a cycle of work
and waiting. Blocking is done at the highest level, computation is executed to
completion and waiting occurs again. Preemptive multithreading pre-allocates RAM
that cannot be used even while not in use by the owning thread. What is needed is a
concurrency model that balances the programming needs through a preemptive
threading model and at the same time meets the resource constraints of sensing
devices.
We introduce a hybrid approach called Y-Threads. Y-Threads are preemptive
multithreads with small thread stacks. The majority of work in Y-Threads is done by
non-blocking routines that execute on a separate common stack. By separating the
execution stacks of control and computational behavior, Y-Threads can support
preemptive threading model with better memory utilization than preemptive
multithreading alone.
We have implemented Y-Threads on several WSN platforms. Experimental results
show that a Y-Thread version of a time synchronization application only increased
energy consumption by 0.12% over the original purely multithreaded version. In
addition the worst-case RAM requirement for the Y-Thread implementation was
reduced by 16.5%. Experiments also show that Y-Thread implementations of a flash
modification routine are more processing efficient than versions that dynamically
allocate memory.
The rest of this paper is structured as follows. Section 2 discusses the motivation,
programming model, and implementation of Y-Threads. Experimental test
applications and results are described in Section 3. Section 4 discusses the existing
concurrency models more in depth. Section 5 discusses the possibilities of future
work on Y-Threads. We conclude in Section 6.
2 Y-Threads
Y-Threads are preemptive threads and are well suited to capture the reactive nature of
many WSN programs. It is based on the insight that many WSN applications block,
waiting for specific events to occur, that has motivated the development of Y-
Threads. As events occur, they react by performing atomic computations, changing
their state, and returning to the wait mode. Behavior of many such applications can be
captured in terms of two sets of behavior: the first is a control behavior that is state-
based and that guides the application through different state transitions as different
events occur. The second are the different computational behaviors that occur during
various state transitions.
For instance, consider the time synchronization code sample shown in Fig. 1. The
control behavior is defined in the while loop: the application blocks while waiting for
Sign up today - FREE
Mendeley saves you time finding and organizing research. Learn more
- All your research in one place
- Add and import papers easily
- Access it anywhere, anytime
Start using Mendeley in seconds!
Readership Statistics
5 Readers on Mendeley
by Discipline
by Academic Status
60% Ph.D. Student
20% Researcher (at a non-Academic Institution)
20% Associate Professor
by Country
40% Switzerland
20% Belgium
20% Brazil



