Book contents
- Frontmatter
- Contents
- List of Code examples
- Preface
- Acknowledgements
- Programming hints, condensed
- Part I TinyOS and nesC
- Part II Basic programming
- 3 Components and interfaces
- 4 Configurations and wiring
- 5 Execution model
- 6 Applications
- 7 Mote-PC communication
- Part III Advanced programming
- Part IV Appendix and references
- References
- Index
5 - Execution model
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
- 3 Components and interfaces
- 4 Configurations and wiring
- 5 Execution model
- 6 Applications
- 7 Mote-PC communication
- Part III Advanced programming
- Part IV Appendix and references
- References
- Index
Summary
This chapter presents TinyOS 's execution model, which is based on split-phase operations, run-to-completion tasks and interrupt handlers. Chapter 3 introduced components and modules, Chapter 4 introduced how to connect components together through wiring. This chapter goes into how these components execute, and how you can manage the concurrency between them in order to keep a system responsive. This chapter focuses on tasks, the basic concurrency mechanism in nesC and TinyOS. We defer discussion of concurrency issues relating to interrupt handlers and resource sharing to Chapter 11, as these typically only arise in very high-performance applications and low-level drivers.
Overview
As we saw in Section 3.4, all TinyOS I/O (and long-running) operations are split-phase, avoiding the need for threads and allowing TinyOS programs to execute on a single stack. In place of threads, all code in a TinyOS program is executed either by a task or an interrupt handler. A task is in effect a lightweight deferred procedure call: a task can be posted at anytime and posted tasks are executed later, one-at-a-time, by the TinyOS scheduler. Interrupts, in contrast can occur at any time, interrupting tasks or other interrupt handlers (except when interrupts are disabled).
While a task or interrupt handler is declared within a particular module, its execution may cross component boundaries when it calls a command or signals an event (Figure 5.1).As a result, it isn't always immediately clear whether a piece of code is only executed by tasks or if it can also be executed from an interrupt handler.
- Type
- Chapter
- Information
- TinyOS Programming , pp. 71 - 78Publisher: Cambridge University PressPrint publication year: 2009