Book contents
- Frontmatter
- Contents
- List of Code examples
- Preface
- Acknowledgements
- Programming hints, condensed
- Part I TinyOS and nesC
- Part II Basic programming
- Part III Advanced programming
- 8 Advanced components
- 9 Advanced wiring
- 10 Design patterns
- 11 Concurrency
- 12 Device drivers and the hardware abstraction architecture (HAA)
- 13 Advanced application: SoundLocalizer
- Part IV Appendix and references
- References
- Index
11 - Concurrency
Published online by Cambridge University Press: 05 August 2012
- Frontmatter
- Contents
- List of Code examples
- Preface
- Acknowledgements
- Programming hints, condensed
- Part I TinyOS and nesC
- Part II Basic programming
- Part III Advanced programming
- 8 Advanced components
- 9 Advanced wiring
- 10 Design patterns
- 11 Concurrency
- 12 Device drivers and the hardware abstraction architecture (HAA)
- 13 Advanced application: SoundLocalizer
- Part IV Appendix and references
- References
- Index
Summary
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.
- Type
- Chapter
- Information
- TinyOS Programming , pp. 192 - 205Publisher: Cambridge University PressPrint publication year: 2009