Immortal Threads: Multithreaded Event-driven Intermittent Computing on Ultra-Low-Power Microcontroll
https://www.usenix.org/conference/osdi22/presentation/yildiz
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
Last updated