# Immortal Threads: Multithreaded Event-driven Intermittent Computing on Ultra-Low-Power Microcontroll ### Presentation #### Low-power computing * LoWPANs * Volcano monitoring, structural monitoring, smart home and IoT * Types of wireless network * High cost, high power <-- -->Low cost, low power <-- --> ultra-low cost, ultra-low power * E.g. wifi, bluetooth, LoWPAN (embedded mesh network) * Low-power embedded devices * Hamilton sensor platform * 10 dollars excluding the battery (manufacture) * 32 KiB RAM, 250 kb/s IEEE 802.15.3 radio * All SRAM, no DRAM * RAM limited: power consumption (reason) * This is an example of embedded programming * No OS-supported features into it * Two questions * How should we program such devices? * How can we compose them into larger embedded networked sensor system? * Early thoughts (late 1990s and early 2000s) * Requirements that shape the design of network sensor system * Low power and small size: constrain the processing, storage, and interconnect capability * Highly concurrent: primary mode of operation ... is to flow information from place to place * Little physical parallelism: number of independent controllers, the capabilities of the controllers * More burden put on the CPU * Diverse designs * Application-specific * Unusually robust * No human in the loop * Concurrency model * Threads v.s events debate * Threads are much easier to program, but tricky to sync * Events allow for faster task switching and scale to more concurrent tasks * Writing event-driven code is cumbersome * I2C: bus * State machines * Generate state machines underneath the hood (some of the existing techs) * Making event-driven programming easier * TinyOS * Stack-based cooperative multithreading * Contiki * Preemptive multithreading as a library * Portothreads example * Minimizing the thread states, but complex code in run * pt -> lc (2 bytes) * Stackless: no stack, lose the variables #### Paper * Energy harvesting battery-less devices * Future sensing devices are tiny, sustainable and run forever * Capacitor on the device to store energy * A typical battery-less sensor architecture * Q: FRAM (map to physical address space and it's non-volatile) * Program failures: intermittent execution * Existing techniques * Checkpoint: back up entire state * Costly * Consistent snapshot * Event-driven tasks * Globals: Non-v ram (FRAM) * Task: atomic; non-preemptive and stackless * Checkpoint easily * Stackful concurrency * Programming explicitness * Problem statement * Programming model that * No cognitive load and lightweight as task-based model * Stackful concurrency (preemption + multithreading) * Minimal wasted progress * Pseudo-stackful preemptive multithreading * Immortal threads * Think only event-driven aspects * Identify the events * Threads as event handler * Manage state management and transitions * Compiler frontend * Almost free checkpoints: save only the program counter rather than all registers and memory (just 2 bytes) * Counter of the switch statements of where you were * Stack is always on Non-V memory * Just-in-time privatization * Creates private copies of variables dynamically to keep non-V memory consistent Questions * Immortal threads * break up the execution into idempotent reads and writes * checkpoint after each such memory operation * Why is this faster than prior SOTA * Is intermittent computing really necessary * IPSN 2019: capacity over capacitance for reliable energy * Concurrency is less important now * Depends on the idea: lose power frequently * Add a second power-backup * Reasonable: power budget --> decrease the cost of checkpointing * No dynamic power measurements to do the prediction * Does it support loop and if statement? * Dynamic loop * Statically check each branch in loop body --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://sliu583.gitbook.io/blog/specific-work/seminar-and-talk/berkeley-system-seminar/immortal-threads-multithreaded-event-driven-intermittent-computing-on-ultra-low-power-microcontroll.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.