A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

46 Chapter 3. Programming and Runtime Environments Actual implementations of over-the-air programming often require the cooperation of user-written application code. Over-the-air reprogramming is often provided as a substitute for dynamic process loading by several resourceconstrained sensor-node architectures. It has been deployed, for example, in BTnode system software [21], BTnut [123], TinyOS [45]), Maté [79], and others. A detailed survey of software update management techniques can be found in [51]. 3.4.4 Process Concurrency In a concurrent process model, several processes can run at the same time. Since wireless sensor nodes are typically single-processor systems, concurrent processes need to be interleaved, with the processor multiplexed among them. Processor multiplexing is called scheduling and is typically performed by the system software as it is considered a fundamental system service. The points in the programs where switching is best performed depends on the programs’ internal structure. Therefore, scheduling mechanisms are closely related to programming models and their corresponding execution environments. For sensor nodes two basic scheduling strategies exist. Architectures with an event-driven execution environment typically provide a concurrency model that is also based on events. Systems with a multi-threaded execution environment provide a concurrency model based on context switches. Context-Switching Processes The design of process concurrency based on context switches for sensor nodes can be best understood by comparing it to designs in general-purpose operating systems. Multi-tasking in general-purpose operating systems. Modern general-purpose operating systems have two levels of concurrency—the first level among processes, and the second level among the threads within a process. Both levels have their own scheduling mechanism, which are both based on context switches. Context-switching processes is referred to as multi-tasking. (The terms task and process are often used synonymously.) Multi-threading and multi-tasking are similar in many respects but differ in the way they share resources. They both provide concurrency, the former among the threads of a process, the latter among the processes running on a system. Just like threads, tasks have their own sequential control flow and their own context. And just like multi-threading, multi-tasking requires context switches and individual stacks (one per task) to store context information. Therefore, the system support required for multi-tasking is also very similar to that of multithreading, which we discussed previously in Sect. 3.2.4 on page 38. The main difference to threads is that tasks typically do not share resources, such as files handles and network connections. In particular, tasks have their own memory regions that are protected against accidental access from other tasks. This is desirable to protect correct programs from buggy ones. To provide communication and synchronization amongst processes despite those protec-
3.4. Process Models 47 tive measures, special mechanisms for inter-process communication exist, like shared memory, message passing, and semaphores. The main objectives of process concurrency in general-purpose operating systems is to optimize processor utilization and usability (cf. [108]). While one process is waiting for an input or output operation to commence (e.g., writing a file to secondary storage or waiting for user input), another process can continue its execution. Therefore some process is always running. From a user perspective, process concurrency can increase the systems usefulness and reactivity. Running several programs in parallel allows to share the processing power of a single computer among multiple users. To each of the users it appears as if they had their own (albeit slower) computer exclusively to them. Also, a single user running several applications can switch back and forth between them without having to terminate them. Context-switching sensor-node processes. In order to avoid the resource overhead induced by two layers of scheduling, context-switsched sensor-node operating systems typically only provide a single level of scheduling on the basis of threads. That is, threads are the only scheduled entity. This does not mean, however, that multi-threaded sensor-node operating systems cannot provide process concurrency. If they do, the threads of distinct processes are contextswitched, thereby also switching processes. Processes then consist of a collections of threads, which are indistinguishable from the threads of other processes. The notion of a process is entirely logical, denoting all threads belonging to a program. In simple implementations a fine-grained control mechanism over the CPU time assigned to processes is missing; a process with more threads may receive more CPU time. To dynamically create a new process, the binary image of the program (consisting of a collection of threads) is loaded and all of its threads are instantiated. Threads or tasks? In the face of a single level of context switching, the question my arise, why we consider the context-switched entities of sensor-node system software to be threads rather then processes. This seems to be a rather arbitrary, if not an unusual view, because in the history of modern operatingsystem development, support for concurrent processes (e.g., multi-tasking) was introduced well before concurrency within individual processes, as provided by multi-threading (cf. [27]). In fact, multi-threading was long missing in generalpurpose operating systems. Though threads and tasks are similar in several respects, they have been developed for different reasons and serve different objectives. While multi-tasking aims more at the user of the computer system, multi-threading is mainly an abstraction to aid programmers. In sensor networks, concurrency is mainly considered a tool for specifying reactive programs while supporting multiple processes or even multiple users is considered less important. Also, the context-switched entities in wireless sensor networks have much more in common with threads than processes, because of the way they share resources. Most of the measures to protect distinct processes found in traditional multi-tasking systems are not (and cannot be) implemented in sensor networks. Because of these reasons, the term task has become widely accepted in sensor-network literature to denote context-switched entities.
Page 1:
Diss. ETH Nr. 17397 A State-Based P
Page 4 and 5:
ii The main idea behind OSM is to e
Page 6 and 7: iv These, dass ein solches zustands
Page 8 and 9: vi Contents 2.4.3 Wireless Sensor N
Page 10 and 11: viii Contents 8.2.4 Program State M
Page 12 and 13: 2 Chapter 1. Introduction This make
Page 14 and 15: 4 Chapter 1. Introduction for senso
Page 16 and 17: 6 Chapter 1. Introduction programmi
Page 18 and 19: 8 Chapter 2. Wireless Sensor Networ
Page 20 and 21: 10 Chapter 2. Wireless Sensor Netwo
Page 42 and 43: 32 Chapter 3. Programming and Runti
Page 72 and 73: 62 Chapter 4. Event-driven Programm
Page 94 and 95: 84 Chapter 5. The Object-State Mode
Page 106 and 107:
96 Chapter 5. The Object-State Mode
Page 108 and 109:
98 Chapter 5. The Object-State Mode
Page 110 and 111:
100 Chapter 6. Implementation When
Page 112 and 113:
102 Chapter 6. Implementation speci
Page 114 and 115:
104 Chapter 6. Implementation Progr
Page 116 and 117:
106 Chapter 6. Implementation state
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
112 Chapter 6. Implementation runti
Page 124 and 125:
114 Chapter 6. Implementation PROG_
Page 126 and 127:
116 Chapter 6. Implementation the s
Page 128 and 129:
118 Chapter 6. Implementation the i
Page 130 and 131:
120 Chapter 7. State-based Programm
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
140 Chapter 8. Related Work guage.
Page 152 and 153:
142 Chapter 8. Related Work Control
Page 154 and 155:
144 Chapter 8. Related Work and out
Page 156 and 157:
146 Chapter 8. Related Work applica
Page 158 and 159:
148 Chapter 8. Related Work low-lev
Page 160 and 161:
150 Chapter 8. Related Work
Page 162 and 163:
152 Chapter 9. Conclusions and Futu
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
158 Appendix A. OSM Code Generation
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
176 Appendix B. Implementations of
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
182 Bibliography [11] Charles Andr
Page 194 and 195:
184 Bibliography [36] Cormac Duffy,
Page 196 and 197:
186 Bibliography [60] Jason Lester
Page 198 and 199:
188 Bibliography [85] Alan Mainwari
Page 200 and 201:
190 Bibliography [110] Karsten Stre
Page 202 and 203:
192 Bibliography
show all

A State-Based Programming Model for Wireless Sensor Networks

Create successful ePaper yourself

Delete template?

Save as template?