A Simpler, Safer Programming and Execution Model for Intermittent Systems
Total Page：16
File Type：pdf, Size：1020Kb
A Simpler, Safer Programming and Execution Model for Intermittent Systems Brandon Lucia Benjamin Ransford Carnegie Mellon University, USA University of Washington, USA [email protected] [email protected] Abstract largely avoided using flash because of its unwieldy erase–write Energy harvesting enables novel devices and applications without semantics, write latency that is orders of magnitude slower than batteries, but intermittent operation under energy harvesting poses RAM, limited durability, and high voltage requirements [30, 33]. new challenges to memory consistency that threaten to leave appli- Emerging nonvolatile memories ease the burden of on-chip per- cations in failed states not reachable in continuous execution. This sistent storage for microcontrollers. Ferroelectric RAM (FRAM) in paper presents analytical models that aid in reasoning about inter- production chips offers convenience, speed, durability, and energy mittence. Using these, we develop DINO (Death Is Not an Option), characteristics closer to those of RAM [34]. Programmers can use a programming and execution model that simplifies programming memory-mapped FRAM to store variables that will survive power for intermittent systems and ensures volatile and nonvolatile data failures. Recent work noted that fast, accessible nonvolatile storage consistency despite near-constant interruptions. DINO is the first can simplify programming models by abstracting process lifecy- system to address these consistency problems in the context of in- cles and working sets [4, 8], appearing to the programmer to offer termittent execution. We evaluate DINO on three energy-harvesting persistence “for free.” hardware platforms running different applications. The applica- This paper demonstrates that intermittent execution will thwart tions fail and exhibit error without DINO, but run correctly with programmers tempted by “free” or cheap persistence. Embedded DINO’s modest 1.8–2.7× run-time overhead. DINO also dramati- ISAs and compilers do not distinguish between writes to non- cally simplifies programming, reducing the set of possible failure- volatile and volatile memory, exposing simple load/store inter- related control transfers by 5–9×. faces that assume the programmer will use hardware correctly— and leaving programs responsible for data consistency. Under in- Categories and Subject Descriptors C.3 [Special-purpose and termittent execution on real hardware platforms, partially executed application-based systems]: Real-time and embedded systems; code and repeated code result in consistency violations that can D.4.5 [Reliability]: Checkpoint/restart break program invariants or corrupt outputs. Power failures at ar- bitrary times introduce implicit control flow that stymies auto- Keywords Intermittent computing mated analysis and complicate programmer reasoning. Worse, sud- den power failures can lead to program states that are unreachable 1. Introduction in any continuous execution, rendering embedded systems unsafe Increasing energy efficiency has lowered the energy cost of com- or unusable. putation so far that general-purpose microcontrollers can operate This paper presents DINO (Death Is Not an Option), a new pro- solely on energy they can scavenge from their surroundings [14, gramming and execution model that addresses the challenges posed 25]. Unlike traditional machines with tethered power or batteries, above. In DINO’s programming model, programmers insert task energy-harvesting computers boot quickly from tiny energy buffers boundaries to subdivide long-running computations into semanti- and operate intermittently. Execution can be interrupted by a power cally meaningful shorter tasks, such as sampling a sensor or manip- failure at any point. ulating an important buffer. Tasks are dynamically formed spans Early prototypes of intermittently powered computers acted of instructions between task boundaries. Tasks have well-defined as programmable, sensor-laden RFID tags and used on-chip flash transactional semantics: the program’s state at a task boundary is memory for program storage [31]. Subsequent efforts built applica- guaranteed to be consistent with the completed execution of the tions such as handshake authentication [10], computer vision [40], task that preceded it. In contrast to software transactional memo- user interaction [36], and data logging [38, 39]. These applications ries (STMs) that clearly distinguish operations protected by trans- actions, in DINO every instruction executes in a transaction. To support this programming model, DINO’s execution model uses judicious checkpointing and recovery that tracks volatile and Permission to make digital or hard copies of part or all of this work for personal or nonvolatile state. This approach is unlike previous systems that classroom use is granted without fee provided that copies are not made or distributed track only volatile state and permit consistency violations involving Permissionfor profit or to commercial make digital advantage or hard and copies that copiesof all or bear part this of notice this work and the for full personal citation or nonvolatile state [16, 28]. By executing all instructions in transac- classroom use is granted without fee provided that copies are not made or distributed on the first page. Copyrights for components of this work owned by others than tional tasks, DINO guarantees that intermittent execution behavior forACM profit must or commercialbe honored. advantage Abstracting and with that credit copies is bear permitted. this notice To andcopy the otherwise, full citation to on the first page. Copyrights for components of this work owned by others than ACM is equivalent to continuous execution behavior. This guarantee sim- mustrepublish, be honored. to post Abstracting on servers, with or to credit redistribute is permitted. to lists, To copy contact otherwise, the Owner/Author. or republish, toRequest post on permissions servers or to from redistribute [email protected] to lists, requires or prior Publications specific permission Dept., ACM, and/or Inc., a plifies programming by eliminating potential failure-induced con- fee.fax +1 Request (212) permissions 869-0481. Copyright from [email protected]. 2015 held by Owner/Author. Publication Rights trol transfers. When a failure occurs, execution simply resumes at Licensed to ACM. Copyright is held by the owner/author(s). Publication rights licensed to ACM. the task boundary that began the current task. PLDI’15 , June 13–17, 2015, Portland, OR, USA PLDI’15Copyright, Junec 2015 13–17, ACM 2015,978-1-4503-3468-6/15/06. Portland, OR, USA . $15.00 ACM.DOI: http://dx.doi.org/10.1145/2737924.2737978 978-1-4503-3468-6/15/06 http://dx.doi.org/10.1145/2737924.2737978 575 This paper makes the following contributions: volatile memory. After a reboot, execution resumes at the check- point rather than main(). • We define the Intermittent Execution Model and present two ways to model intermittence, namely as concurrency and con- Checkpointing is insufficient. Dynamic checkpointing enables trol flow. We use both models to characterize, for the first time, progress and ensures correctness for programs that use only volatile several problems that threaten application consistency on inter- state. However, past work does not address two problems that are mittently powered embedded devices. fundamental to the intermittent execution model. The first problem • We resolve these problems with the DINO programming and is that dynamic checkpoints are opaque and implicit: a program- execution model, which provides task-based programming and mer or static program analysis is forced to guess where execution task-atomic execution to avoid consistency violations under will resume after a reboot, and every instruction that can execute intermittent power. is a candidate. Inferring the set of possible resumption states re- • quires complex reasoning about many program scopes and func- We evaluate a working prototype of DINO, including a com- tions. Non-idempotent operations, like I/O and nonvolatile mem- piler and runtime system for embedded energy-harvesting plat- ory accesses, may be unpredictably repeated or partially completed. forms. We evaluate DINO on diverse real systems and applica- Under dynamic checkpointing alone, these factors confound analy- tions and show that DINO provides its guarantees effectively sis by programmers and compilers. and efficiently. The second fundamental problem is that, despite its persistence, nonvolatile memory does not necessarily remain consistent across 2. Intermittent Execution: Key Challenges reboots—potentially leaving it in a state that is not permitted by any continuous execution. Errors from partial or repeated execution can Intermittent execution presents fundamental, unsolved challenges accumulate in nonvolatile memory, with results ranging from data- to programmers of energy-harvesting systems that have volatile structure corruption to buffer overflows. Such problems may occur and nonvolatile state. This work’s goal is to address these chal- even in code that is correct under continuous execution. The poten- lenges and provide a reliable, intuitive foundation for such sys- tial for memory inconsistency forces the programmer to manually tems. This section describes an intermittent execution model to fa- and onerously reason about, check, and enforce consistency wher- cilitate reasoning about programs on intermittently powered de- ever nonvolatile data is accessed. vices. It formalizes and enriches the implicit model