Macroprogramming

1. Macroprogramming Eric Brewer (with help from David Gay, Rob von Behren, and Phil Levis)

2. Outline • Introduction • NesC Midterm Plans • Macroprogramming WEBS Retreat

3. Language Goals • Short term (NesC) • Make it much easier to program single motes • Gain experience with the issues (please tell us!) • Build intermediate language for future work • Long term (macroprogramming) • Write high-level programs for groups of motes • Deal with failure and uncertainty, varying numbers of motes • Abstract issues of time, location, neighbors • Provide implicit communication and data sharing • Enable low power and bandwidth efficiency WEBS Retreat

4. NesC Midterm Goals • Version 1 ready now • Cleans up wiring and code • Smaller, faster, faster to compile code • Potential areas for the next version: • Simplify split-phase calls • Blocking calls at the higher level? • At least simplify creation of the command/event pair • Manage state across split-phase calls • “pass” values (like message buffer) • Pass by reference, but object leaves your scope • Implies passed thing is NOT shared • Simplifies capabilities, events, pipelines WEBS Retreat

5. NesC Midterm (cont) • Definition of messages • Define a message type and then create surrounding code • Dynamic Linking? • Enable larger programs, multi-mode motes • Load modules from EEPROM? from network? • Support for proxies? • Sleep modes/timing? • Explicit support for state machines? • Probably for interfaces/protocols WEBS Retreat

6. NesC Midterm (cont) • Big goal: race-free, deadlock-free programs • Key idea: • We can know all of the global resources statically • We can find atomic sections for every resource use • We can track which resources are in use • We can avoid running things that conflict (run things that release resources) • We believe that we can detect and enforce every critical section. • Requires a scheduler (and no multiprocessing) • Claim: would have prevented Therac-25, Mars Rover WEBS Retreat

7. Macroprogramming • Roughly: programming language plus runtime system • Basics: • One program for many motes • Shared view of the world, some shared state • Higher level programming language • Should provide for sure: • Logical location (2D for now), with error radius • Explicitly know mobile or fixed • Time synchronization, with error bound • Global sleep scheduling? • Time series as a first class type • A sequence of values over time (with error bounds!) • Operations on the sequence (e.g. window, max, last) WEBS Retreat

8. Macro: Tree Support • Claim: spanning tree is a key concept • Runtime provides a logical spanning tree • One per partition, split/merge automatically • Changes over time, but operations can still be ordered • Motes need not know whole tree, just local area/direction • Enables tree operations: • Barrier (local to partition) • Broadcast • Gather with aggregation (statistical) • Scatter (can affect on way down) • Gather and broadcast with aggregation WEBS Retreat

9. Macro: Tree Aggregation • Key idea: combining function (cf) v’ = cf(v, a) // new value is a function of old plus an argument • Cf is associative and commutative cf(cf(v, a), b) == cf(cf(v, b), a) • Given two args, a and b c = G(a, b) Require: cf(cf(v, a), b) = cf(v, c) • this allows us to combine args without knowing v • … and thus combine args up the tree • Can also compute result after fixing a partition • Log only the aggregate arg, not all of the updates • Examples: addition, min/max, latest WEBS Retreat

10. Macro: using CF trees • At language level: • Enables reliable aggregation efficiently • Can sometimes compute G from cf given by user • Can also allow explicit definition of G (and cf) • Easy to do: • Shared state that maintains latest value, min or max • “horizontal” arrays with global operations! • Readers/Writers shared state with cf for writes • App just makes local update; we handle the communication and consistency • Harder: • Automatic conflict resolution after partition ends? • Automatic generation of cf given an expression? • Multi-arg combiner functions, including error terms WEBS Retreat

11. Macro: 2D Spaces • Alternative framework to logical spanning tree • Based on 2D virtual grid • Motes have locations (not on grid points) • Operations for areas, gradients, spatial neighbors • Easier for fixed placements • Two phases: discovery and use • Discovery does all-way localization (using some known nodes), and determines neighbor structures • Creates a quad tree instead of logical spanning tree • Use is both tree operations and spatial operations • Claim: shared infrastructure is the key to NEST WEBS Retreat

12. Other issues • Multi-mode programs? • Construct different programs for different kinds of motes automatically • How to exploit high resource motes? • Power, bandwidth, connectivity? • Rough approach: bimodal • Lite motes worry about power/bandwidth • Heavy motes do not • Two programs generated (or one with two parts) • Weakly consistent sharing (e.g. bayou)? • Generate software for proxies, PCs? • Support 3D spaces? 2½ D WEBS Retreat

13. Conclusions • Key is really the shared runtime system • Logical spanning tree • Logical 2D grid • Shared state • Can’t make new routing for each app… • Error propagation/merging must be central • Looking for feedback! • What are the problems we need to solve? WEBS Retreat