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