TOSThreads Tutorial (TOS 2.1.1)

This lesson discusses the TOSThreads library with the following objectives:

• Give readers an high-level overview of the library.
• Give a summary of the currently available services supported by the TOSThreads library.
• Demonstrate how to use the nesC API to create and manipulate both static and dynamic threads.
• Demonstrate how to use the C API to create and manipulate threads.
• Demonstrate how to add TOSThreads support to new system services.

Note: TOSThreads is part of TinyOS since release 2.1.

TOSThreads

TOSThreads combines the ease of a threaded programming model with the efficiency of a fully event-based OS. In fact, TOSThreads adds an additional execution class to TinyOS in the following sense. The existing TinyOS concurrency model has two classes of execution: synchronous (tasks) and asynchronous (interrupts). They follow a hierarchy: asynchronous code can preempt synchronous code but synchronous code is run-to-completion. TOSThreads extends this concurrency model with user-level application threads. Application threads cannot preempt either synchronous or asynchronous code, but can preempt one another. Application threads synchronize using standard primitives such as mutexes, semaphores, barriers, and condition variables.

Compared to earlier threads packages designed for TinyOS, TOSThreads offers the following benefits:

1. It supports fully-preemptive application-level threads.
2. It does not need explicit continuation management, such as state variables between corresponding commands and events.
3. It does not violate TinyOS's concurrency model.
4. It requires minimal changes to the existing TinyOS code base. In addition, adding TOSThreads support to a new platform is a fairly easy process.
5. It offers both nesC and C APIs.

Architecture

In TOSThreads, TinyOS runs inside a single high-priority kernel thread, while the application logic is implemented in user-level threads. Since the TinyOS kernel thread has a higher priority, user-level threads execute whenever the TinyOS kernel thread becomes idle. This approach is a natural extension to the existing TinyOS concurrency model: adding support for long-running computations while preserving the timing-sensitive nature of TinyOS itself.

In this model, application threads access underlying TinyOS services using a kernel API of blocking system calls. The kernel API defines the set of TinyOS services provided to applications, such as radio, collection (TEP119), and so on. Each system call in the API is comprised of a thin blocking wrapper built on top of one of these services. The blocking wrapper is responsible for maintaining states across the non-blocking split-phase operations. This transfer of control between the TinyOS kernel thread and application threads resembles message passing. This approach ensures that application threads do not touch the kernel code directly, and makes it easier to build a thread-safe system.

TOSThreads provides both nesC and C flavor of kernel APIs. This means that users can choose to code TOSThreads applications in either nesC or C. Later sections of this tutorial discusses how to write TOSThreads applications, and how to implement kernel APIs for new TinyOS services.