TOSThreads: Extending the TinyOS Concurrency Model to Support Preemption Kevin Klues?, Chieh-Jan Mike Liangy, Jeongyeup Paekz, Razvan Musaloiu-Ey, Ramesh Govindanz, Philip Levis?, Andreas Terzisy ? Stanford University y Johns Hopkins University z University of Southern California Stanford, CA Baltimore, MD Los Angeles, CA ABSTRACT On the other hand, preemptive threading offers a more We present TOSThreads, an application-level threads intuitive programming paradigm for developing higher- package for TinyOS. In contrast to previous threads level services and applications. In this model, applica- packages proposed for TinyOS, TOSThreads supports tion writers need not explicitly manage yield points or fully preemptive threads while maintaining the exist- continuations, or partition a long running computation ing TinyOS concurrency model. TOSThreads defines a to avoid missing events. Compression is a concrete ex- conceptual user/kernel boundary, whereby TinyOS runs ample of an operation that can benefit from threading. as a high-priority kernel thread and application threads Many sensor network applications, such as seismic sens- execute at lower priority. This approach naturally sup- ing [27] and structural monitoring [2, 15] could benefit ports long-running computations while preserving the greatly from data compression. Nevertheless, real sensor timing-sensitive nature of TinyOS itself. Additionally, network deployments rarely use it due to the difficulty the existence of a user/kernel boundary enables dynamic of implementing it in event-driven environments. linking and loading of application binaries at runtime. In this paper, we explore this tension between being The API at this boundary defines the set of TinyOS able to manage concurrency in the face of resource con- services supported by a TOSThreads kernel and is cus- straints and having an intuitive programming model. tomizable in support of a diverse set of applications. Specifically, we describe a new threads package called We demonstrate that TOSThreads context switches TOSThreads for TinyOS that has several novel goals: and system calls introduce an overhead of less than Fully preemptive threads: Application programmers 0.92% and that dynamic linking and loading takes as should not have to manually manage yield points or con- little as 90ms for a representative sensing application. tinuations, greatly simplifying application development. We compare different programming models built on top Minimal disruption: Adding threads should not neg- of TOSThreads, including standard C with blocking sys- atively affect the OS's performance and changes required tem calls and a reimplementation of Tenet. Addition- to the existing code should be highly localized and min- ally, we evaluate the ability of TOSThreads to run com- imal. This goal enables system developers to achieve putationally intensive tasks. Taken as a whole, these high performance and concurrency wherever necessary. results suggest that TOSThreads is an important step towards defining a TinyOS kernel that can support long- Flexible boundary: Developers must be able to ex- running computations and high concurrency. periment with different \kernels" by altering the bound- aries between threaded and event-driven code, based on 1. INTRODUCTION tradeoffs between ease of use, efficiency, and application requirements. Many mote operating systems use event-driven exe- cution to support multiple concurrent execution con- Flexible application development: The system must texts with the memory cost of a single stack [6, 11, enable programmers to develop their applications using 13]. Network protocols, storage subsystems, and sim- multiple programming paradigms and provide a way to ple data filters can be easily developed in this model, as dynamically link and load executable application code. they typically perform short computations in response To the best of our knowledge, no existing thread pack- to I/O events. More generally, there are sound rea- age for TinyOS satisfies all of these requirements. Tiny- sons for mote OSs to be event-based: given the motes' Threads [21] relies on applications to explicitly yield the memory and processing constraints, an event-based OS processor. TinyMOS [25] runs TinyOS inside a ded- permits greater concurrency than other alternatives. icated Mantis [1] thread, but requires placing a lock around most of the TinyOS code, limiting overall con- System Calls currency and efficiency. While our work has been in- Application Task spired by these approaches, TOSThreads is different Threads Scheduler as it provides true multi-threading in TinyOS without limiting performance or sacrificing its event-driven pro- TinyOS gramming model. Thread Contributions. We identify three contributions re- lated to the goals we have just set forth. (1). We pro- Thread Scheduler vide TOSThreads, a fully-preemptive threads library for TinyOS. In TOSThreads, TinyOS runs inside a high pri- Figure 1: Overview of the basic TOSThreads architec- ority kernel thread, while all application logic resides in- ture. The vertical line separates user-level code on the side user-level threads, which execute whenever TinyOS left from kernel code on the right. Looping arrows indi- cate running threads, while the blocks in the middle of becomes idle. This approach naturally extends the ex- the figure indicate API slots for making a system call. isting TinyOS concurrency model while adding support for long-running computations. (2). TOSThreads ap- plications access underlying TinyOS services through supporting long-running computations. a kernel API of blocking system calls. This frame- work allows system developers to evolve the kernel API 2. ARCHITECTURE by wrapping blocking system calls around event-driven The existing TinyOS concurrency model has two exe- TinyOS services. Moreover, by exporting this API in cution contexts: synchronous (tasks) and asynchronous both nesC [9] and ANSI C, we allow developers to im- (interrupts). These two contexts follow a strict priority plement efficient applications without the need to learn scheme: asynchronous code can preempt synchronous a new language. (3). TOSThreads enables on-demand code but not vice-versa. TOSThreads extends this con- execution of application threads received from the net- currency model to provide a third execution context in work as binary objects. TinyLD, our dynamic linker- the form of user-level application threads. While ap- loader, patches a binary's unresolved system call refer- plication threads cannot preempt either synchronous or ences and loads it into the mote's memory before exe- asynchronous code, they can preempt each other. Appli- cuting it. cation threads synchronize using standard synchroniza- In many ways, the TOSThreads approach resembles tion primitives such as mutexes, semaphores, barriers, that taken in Contiki, where the Contiki core runs in condition variables, and blocking reference counters (a one thread and additional threads context switch with mechanism we have developed, x3.4). it. Our contribution beyond this work is to propose Figure 1 presents the TOSThreads architecture, con- message passing between the application threads and sisting of five key elements: the TinyOS task scheduler, the core OS thread, thereby avoiding the race condi- a single kernel-level TinyOS thread, a thread scheduler, tions typical to preemptive threads that directly call a set of user-level application threads, and a set of sys- kernel code. The challenges such race conditions present tem call APIs and their corresponding implementations. perhaps explain why no Contiki platform currently sup- Any number of application threads can concurrently ex- ports thread preemption [4]. ist (barring memory constraints), while a single kernel Together, user-level threads, dynamic application load- thread runs the TinyOS task scheduler. The thread ing and linking, and a flexible blocking system call API, scheduler manages the concurrency between application greatly simplify existing programming abstractions for threads, while a set of system calls provides access to the TinyOS and the implementation of new ones. While TinyOS kernel. these facilities are, of course, available on general-purpose In order to preserve the timing-sensitive nature of systems today, they have not previously been demon- TinyOS, the kernel thread has higher priority than ap- strated together in the context of the TinyOS event-driven plication threads. So long as the TinyOS task queue is operating system. To substantiate TOSThreads's flex- non-empty, this TinyOS thread takes precedence over ibility we have reimplemented the Tenet programming all application threads. Once the TinyOS task queue system [10], on top of TOSThreads. The resulting sys- empties, control passes to the thread scheduler and ap- tem has higher expressivity without increasing code size. plication threads can run. The processor goes to sleep TOSThreads has also enabled the development of a novel only when either all application threads have run to programming language, Latte, a JavaScript dialect that completion, or when all threads are waiting on synchro- compiles to C. Finally, our evaluation results show that nization primitives or blocked on I/O operations. TOSThreads generates minimal overhead in terms of ex- There are two ways in which posted events can cause ecution speed and energy consumption, while efficiently the TinyOS thread to wake up. First, an application thread can issue a blocking system call into the TinyOS Through its flexible user/kernel