So far, the code we've lookedat has been split-phase andruns in tasks (synchronous). This programming model is sufficient for almost all application-level code. High-performance applications and low-level device drivers sometimes require additional functionality and concurrency models. This chapter describes two such additional mechanisms: asynchronous code and resource locks. Asynchronous code is a feature of the nesC language, while resource locks are a set of TinyOS components and mechanisms.

Asynchronous code

Tasks allow software components to emulate the split-phase behavior of hardware. But they have much greater utility than that. They also provide a mechanism to manage preemption in the system. Because tasks run atomically with respect to one another, code that runs only in tasks can be rather simple: there's no danger of another execution suddenly taking over and modifying data under you. However, interrupts do exactly that: they interrupt the current execution and start running preemptively.

The async keyword

As we saw in Chapter 5, nesC distinguishes between synchronous (sync) and asynchronous (async) code. Commands and events that can run preemptively from interrupt handlers (and therefore asynchronously with regards to tasks), must be labeled with the async keyword, both in the interface where the command or event is declared and in the module where the command or event is implemented. As a result, an async command or event, or a function reachable from an async command or event can only call or signal async commands and events (nesC will tell you when you break this rule). This rule means that it's clear from looking at an interface or module which code is synchronous and which is asynchronous.