Safe System-Level Concurrency on Resource-Constrained Nodes
Total Page:16
File Type:pdf, Size:1020Kb
Safe System-level Concurrency on Resource-Constrained Nodes Accepted paper in SenSys’13 (preprint version) Francisco Sant’Anna Noemi Rodriguez Roberto Ierusalimschy [email protected] [email protected] [email protected] Departamento de Informatica´ – PUC-Rio, Brazil Olaf Landsiedel Philippas Tsigas olafl@chalmers.se [email protected] Computer Science and Engineering – Chalmers University of Technology, Sweden Abstract as an alternative, providing traditional structured program- Despite the continuous research in facilitating program- ming for WSNs [12, 7]. However, the development pro- ming WSNs, most safety analysis and mitigation efforts in cess still requires manual synchronization and bookkeeping concurrency are still left to developers, who must manage of threads [24]. Synchronous languages [2] have also been synchronization and shared memory explicitly. In this paper, adapted to WSNs and offer higher-level compositions of ac- we present a system language that ensures safe concurrency tivities, considerably reducing programming efforts [21, 22]. by handling threats at compile time, rather than at runtime. Despite the increase in development productivity, WSN The synchronous and static foundation of our design allows system languages still fail to ensure static safety properties for a simple reasoning about concurrency enabling compile- for concurrent programs. However, given the difficulty in time analysis to ensure deterministic and memory-safe pro- debugging WSN applications, it is paramount to push as grams. As a trade-off, our design imposes limitations on many safety guarantees to compile time as possible [25]. As the language expressiveness, such as doing computationally- an example, shared memory is widely used as a low-level intensive operations and meeting hard real-time responsive- communication mechanism, but current languages do not ness. We implement widespread network protocols and the go beyond runtime atomic access guarantees, either through CC2420 radio driver to show that the achieved expressive- synchronization primitives [7, 27], or by adopting coopera- ness and responsiveness is sufficient for a wide range of tive scheduling [21, 17]. Requiring explicit synchronization WSN applications. The implementations show a reduction primitives lead to potential safety hazards [24]. Enforcing around 25% in code complexity, with a penalty of mem- cooperative scheduling is no less questionable, as it assumes ory increase below 10% in comparison to nesC. Overall, we that all accesses are dangerous. The bottom line is that exist- ensure safety properties for programs relying on high-level ing languages cannot detect and enforce atomicity only when control abstractions that also lead to concise and readable they are required. code. In this work, we present the design of CEU´ 1, a syn- 1 Introduction chronous system-level programming language that provides a reliable yet powerful set of abstractions for the develop- System-level development for WSNs commonly fol- ment of control-intensive WSN applications. CEU´ is based lows three major programming models: event-driven, multi- on a small set of control primitives similar to Esterel’s, lead- threaded, and synchronous models. In event-driven pro- ing to implementations that more closely reflect program gramming [19, 11], each external event can be associated specifications [8]. In addition, CEU´ provides a disciplined with a short-lived function callback to handle a reaction to policy for typical system-level functionality, such as low- the environment. This model is efficient, but is known to be level access to C and shared memory concurrency. It also difficult to program [1, 12]. Multi-threaded systems emerged introduces the following new safety mechanisms: first-class timers to ensure that timers in parallel remain synchronized (not depending on internal reaction timings); finalization blocks for local pointers going out of scope; and stack-based communication that avoids cyclic dependencies. We propose Permission to make digital or hard copies of all or part of this work for personal or a static analysis that considers all language mechanisms and classroom use is granted without fee provided that copies are not made or distributed detects safety threats at compile time, such as concurrent for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute accesses to shared memory, and concurrent termination of to lists, requires prior specific permission and/or a fee. timers and threads. Our work focus on concurrency safety, ACM 1Ceu´ is the Portuguese word for sky. /* nesC */ /* Protothreads */ /* CEU´ */ event void Boot.booted () f int main () f par/or do call T1.startOneShot(0) PT INIT(&blink); loop do call T2.startOneShot(60000) timer set(&timeout, 60000); Leds led0On(); g while ( await 2s; event void T1.fired () f PT SCHEDULE(blink()) && Leds led0Off(); static int on = 0; !timer expired(timeout) await 1s; if (on) f ); end call Leds.led0Off(); leds off(LEDS RED); with call T1.startOneShot(1000); <...> // CONTINUE await 1min; g else f g end call Leds.led0On(); PT THREAD blink () f Leds led0Off(); call T1.startOneShot(2000); while (1) f <...> // CONTINUE g leds on(LEDS RED); on = !on timer set(&timer, 2000); g PT WAIT UNTIL(expired(&timer)); event void T2.fired() f leds off(LEDS RED); call T1.cancel(); timer set(&timer, 1000); call Leds.led0Off(); PT WAIT UNTIL(expired(&timer)); <...> // CONTINUE g } g Figure 1. “Blinking LED” in nesC [17], Protothreads [12], and CEU´ . The colors associate chunks of code with respective actions in the diagram. rather than type safety [9].2 tween sampling a sensor and broadcasting its readings has a In order to enable the static analysis, CEU´ programs must sequential pattern (with an enclosing loop); while including undergo some limitations. Computations that run in un- an 1-minute timeout to interrupt an activity denotes a parallel bounded time (e.g., compression, image processing) cannot pattern. be elegantly implemented [29], and dynamic support, such Figure 1 presents the three different programming mod- as dynamic loading is forbidden. However, we show that els commonly used in WSNs. It shows the implementations CEU´ is sufficiently expressive for the context of WSN ap- in nesC, Protothreads, and CEU´ for an application that con- plications. We successfully implemented the CC2420 radio tinuously lights on a LED for 2 seconds and off for 1 sec- driver, and the DRIP, SRP, and CTP network protocols [32] ond. After 1 minute of activity, the application turns off the in CEU´ . The implementations reduced code complexity by LED and proceeds to another activity (marked in the code as 25%, with an increase in ROM and RAM below 10% in com- <...>). The diagram on the right of Figure 1 describes the parison to nesC [17]. overall control behavior for the application. The sequential The rest of the paper is organized as follows: Section 2 programming pattern is represented by the LED alternating gives an overview on how different programming models between the two states, while the parallel pattern is repre- used in WSNs can express typical control patterns. Sec- sented by the 1-minute timeout. tion 3 details the design of CEU´ , motivating and discussing nesC the safety aspects of each relevant language feature. Sec- The first implementation in , which represents event-driven tion 4, evaluates the implementation of the network protocols the model, spawns two timers at boot time (Boot.booted): one to make the LED blink and another to wait in CEU´ and compares some aspects with nesC (e.g. memory usage and tokens count). We also evaluate the responsive- for 1 minute. The callback T1.fired continuously toggles the LED and resets the timer according to the state variable ness of the radio driver written in CEU´ . Section 5 discusses on. The callback T2.fired executes only once, canceling the related work to CEU´ . Section 6 concludes the paper and makes final remarks. blinking timer, and proceeds to <...>. Overall, we argue that this implementation has little structure: the blinking loop is 2 Overview of Programming Models not explicit, but instead, relies on a static state variable and WSN applications must handle a multitude of concurrent multiple invocations of the same callback. Furthermore, the events, such as timers and packet transmissions. Although timeout handler (T2.fired) requires specific knowledge about they may seem random and unrelated for an external ob- how to stop the blinking activity manually (T1.cancel()). server, a program must logically keep track of them accord- The second implementation in Protothreads, which rep- ing to its control specification. From a control perspective, resents the multi-threaded model [12, 7], uses a dedicated sequential programs are composed of two main patterns: , thread to make the LED blink in a loop. This brings more i.e., an activity with two or more states in sequence; and structure to the solution. The main thread also helps a reader parallel , i.e., unrelated activities that eventually need to syn- to identify the overall sequence of the program, which is not chronize. As an example, an application that alternates be- easily identifiable in the event-driven implementation with- 2We consider both safety aspects to be complimentary and orthogonal, out tracking the dependencies among callbacks. However, it i.e., type-safety techniques could also be applied to CEU´ . still