Bugs in the Wires or, An Exercise in Language Design David Gay Intel Research Berkeley

Introduction Observation 1: debugging sensor network programs is hard Observation 1: debugging sensor network programs is hard Observation 2: nesC makes wiring, i.e., connecting components of a nesC program, easy; this also means that it’s easy to miswire Observation 2: nesC makes wiring, i.e., connecting components of a nesC program, easy; this also means that it’s easy to miswire example 1: forgetting to wire initialisation code example 1: forgetting to wire initialisation code example 2: mistakenly wiring components together twice example 2: mistakenly wiring components together twice Goal: add a simple language extension to catch these kinds of errors Goal: add a simple language extension to catch these kinds of errors

Background: Modules and Wiring module BlinkM { provides interface Init; provides interface Init; uses interface Timer; uses interface Timer;} implementation { command Init.init() { command Init.init() { call Timer.setRate(); call Timer.setRate(); } event Timer.fired() { } event Timer.fired() { }} interface Init { command init(); command init();} interface Timer { command setRate(); command setRate(); event fired(); event fired();} Interfaces are bi-directional. BlinkM can call setRate and must implement init and fired. BlinkM Init.init Timer.fired Timer.setRate C functions function calls

Background: Configurations configuration Blink { provides interface Init; provides interface Init;} implementation { components TimerM, BlinkM; components TimerM, BlinkM; Init = BlinkM.Init; Init = BlinkM.Init; BlinkM.Timer -> TimerM.Timer; BlinkM.Timer -> TimerM.Timer;} interface Init { command init(); command init();} Init.init Blink interface Timer { command setRate(); command setRate(); event fired(); event fired();} TimerM Timer.fired BlinkM Init.init Timer.fired Timer.setRate

Wiring Graph is Very Flexible Can build nearly arbitrary graphs, except: Can build nearly arbitrary graphs, except: module function nodes have 0-outdegree module function nodes have 0-outdegree module call nodes have 0-indegree module call nodes have 0-indegree

Wiring Bug Examples BlinkM’s provided Init interface not wired BlinkM’s provided Init interface not wired  BlinkM never gets initialised BlinkM’s provided Init interface wired twice BlinkM’s provided Init interface wired twice possible incorrect behaviour possible incorrect behaviour provided Timer interface non-shareable, wired twice provided Timer interface non-shareable, wired twice  incorrect behaviour (wrong rate in one user) used split-phase interface wired twice used split-phase interface wired twice ex: interface Send { command send(); event sendDone(); } ex: interface Send { command send(); event sendDone(); }  two responses on every request, will misbehave

Component Graph Example (1)

Component Graph Example (2)

Wiring Bugs: The Fix BlinkM’s provided Init interface not wired BlinkM’s provided Init interface not wired  BlinkM never gets initialised BlinkM’s provided Init interface wired twice BlinkM’s provided Init interface wired twice possible incorrect behaviour possible incorrect behaviour provided Timer interface non-shareable, wired twice provided Timer interface non-shareable, wired twice  incorrect behaviour (wrong rate in one user) used split-phase interface wired twice used split-phase interface wired twice ex: interface Send { command send(); event sendDone(); } ex: interface Send { command send(); event sendDone(); }  two responses on every request, will misbehave Fixes: restrict wiring cardinality Fixes: restrict wiring cardinality ≥ 1 = 1 ≤ 1 = 1

Wiring Bugs: The Fix module BlinkM { provides interface provides interface uses interface uses interface implementation { command Init.init() { command Init.init() { call Timer.setRate(); call Timer.setRate(); } event Timer.fired() { } event Timer.fired() { : new syntax for annotations (see Java : new syntax for annotations (see Java 1.5) atmostonce, atleastonce, exactlyonce : atmostonce, atleastonce, exactlyonce : wiring annotations on provided, used interfaces wiring annotations on provided, used interfaces apply to each function in an interface apply to each function in an interface imply a global check on program’s wiring graph imply a global check on program’s wiring graph

Bugs in Language Design What do the annotations mean? What do the annotations mean? Obvious proposal: node in/out degree Obvious proposal: node in/out degree ≤1

Bugs in Language Design What do the annotations mean? What do the annotations mean? Obvious proposal: node in/out degree Obvious proposal: node in/out degree “Correct” answer appears to be: “Correct” answer appears to be: provided functions: number of paths to this function provided functions: number of paths to this function used functions: number of paths from this function call used functions: number of paths from this function call ≤1

Another Problem What does this mean in a configuration? What does this mean in a configuration? Is this program right? wrong? Is this program right? wrong? provides interface

Another Problem What does this mean in a configuration? What does this mean in a configuration? Is this program right? wrong? Is this program right? wrong? Proposal: correct rule is: Proposal: correct rule is: provided function: check number of paths to this node provided function: check number of paths to this node used function: check number of paths from this node used function: check number of paths from this node note: for bi-directional interfaces, this means that you check both the paths to and from the node note: for bi-directional interfaces, this means that you check both the paths to and from the node provides interface

Does this do all we want? Matched request/reply makes split-phase programs simpler Matched request/reply makes split-phase programs simpler  Let’s use exactlyonce ! module Simple { uses interface Send; uses interface Send;} implementation { int state; int state; void somefn() { void somefn() { state = SENDING; state = SENDING; call Send.send(); call Send.send(); } event Send.sendDone() { event Send.sendDone() { if (state == SENDING) … if (state == SENDING) … }} interface Send { command send(); command send(); event sendDone(); event sendDone();}

Does this do all we want? Matched request/reply makes split-phase programs simpler Matched request/reply makes split-phase programs simpler  Let’s use exactlyonce ! Code is simpler Code is simpler module Simple { uses interface Send uses implementation { void somefn() { void somefn() { call Send.send(); call Send.send(); } event Send.sendDone() { event Send.sendDone() { … }} interface Send { command send(); command send(); event sendDone(); event sendDone();}

Does this do all we want? Matched request/reply makes split-phase programs simpler Matched request/reply makes split-phase programs simpler  Let’s use exactlyonce ! Code is simpler Code is simpler Check is insufficient  Check is insufficient  module Simple { uses interface Send uses implementation { void somefn() { void somefn() { call Send.send(); call Send.send(); } event Send.sendDone() { event Send.sendDone() { … }} Simple =1 send sendDone interface Send { command send(); command send(); event sendDone(); event sendDone();}

Conclusion Wiring bugs are hard to find Wiring bugs are hard to find Some of these bugs can be caught with annotations that restrict paths in the wiring graph: Some of these bugs can be caught with annotations that restrict paths in the wiring graph: atleastonce : at least one path to/from here atleastonce : at least one path to/from here atmostonce : at most one path to/from here atmostonce : at most one path to/from here exactlyonce : exactly one path to/from here exactlyonce : exactly one path to/from here Does not cover all needs Does not cover all needs could add singlepath : all nodes in path have in/out degree at most one could add singlepath : all nodes in path have in/out degree at most one The annotation syntax will be in nesC 1.2, and will be user-extensible (see Java 1.5 specification for general idea) The annotation syntax will be in nesC 1.2, and will be user-extensible (see Java 1.5 specification for general idea)