Building up to Macroprogramming: An Intermediate Language for Sensor Networks

1
Building up to Macroprogramming An Intermediate
Language for Sensor Networks

• Ryan Newton, Arvind (MIT) and
• Matt Welsh (Harvard)
• Presented by Gordon Wong

2
Outline

• Background
• Macroprogramming
• Motivation and Goal
• Distributed Token Machines (DTM)
• Token Machine Language (TML)
• Evaluation
• Conclusion

3
Background

• Sensor Network
• Highly distributed System
• Resource constraints
• NesC
• An extension of the C language
• Low level
• Concurrency, computation and communication mixed
  together
• Difficult for the end-users to program
• Need to develop better programming tools
• High level program model

4
Macroprogramming

• Allow application designer to write code in a
  high level language
• Captures the operation of the sensor network as a
  whole
• Compiled into a form that executes on individual
  nodes
• http//www.eecs.harvard.edu/mdw/proj/mp/

5
Motivation

• Previous work of Newton and Welsh
• Regiment 2004
• Region Streams Functional Macroprogramming for
  Sensor Networks
• Based on functional reactive programming
• Functional macroprogramming language for sensor
  network
• Represents nodes as streams of data
• Grouped into regions for the purpose of
  in-network aggregation or detecting events

6
Motivation

• Problem
• Semantic gap between Regiment and NesC is large
• Leads to difficult compilation
• Solution
• An intermediate Language is needed

Regiment
Semantic Difference
Intermediate Language
NesC
7
Goal

• An intermediate language for sensor network
• Provides simple and versatile abstractions for
  communication, data dissemination, and remote
  execution
• Constitutes a framework for network coordination
  that can be used to implement sophisticated
  algorithms
• Requirement
• Abstract away from the detail of concurrency and
  communication
• Capture enough details for compilers optimization

8
Distributed Token Machine (DTM)

• Distributed Token Machine
• Token based execution and communication model
• Communication happens through token
• Typed message with a small payload
• Tokens are associated with token handlers

9
Distributed Token Machine (DTM)

• Scheduler processes incoming token
• Token Object stored token
• Shared Memory shared among handlers
• Token Message the form tokens take when
  traveling over the network

10
DTM in Action

1. A token Message arrives at the scheduler.
2. The token name directs it to the corresponding
   handler.
3. The handler finds the corresponding token object
   in the token store. If the corresponding token
   object is not present, its memory is allocated
   and initialized to zero
4. The handler consumes the message payload and
   executes atomically
5. May read/write token objects private memory or
   nodes shared memory
6. New messages may be posted

11
Token Handler

• Interfaces
• schedule(Ti, priority, data...)
• timed_schedule(...)
• Insert a token message to the nodes local
  scheduler
• Timed - Insert a token message to the nodes
  local scheduler after a precise time period
• bcast(Ti, data...)
• Broadcast a token message to the neighbors
• No ACK
• is_scheduled(Ti)
• deschedule(Ti)
• Query/removal of token messages waiting in the
  scheduler
• present(Ti)
• evict(Ti)
• Interface into the nodes Token Store as a whole
• Query/remove of Token Objects to/from local
  nodes Token Store

12
Token Machine Language (TML)

• Realization of the DTM
• Fills in set of basic operators and a concrete
  syntax for describing handlers
• Language used
• Subset of C extended with the DTM interface
• No data pointer
• Only allows fixed length loop
• Procedure call is the scheduling of token

13
Goal of TML

• Goals of TML
• Lightweight
• Otherwise, compilation from high-level language
  to TML will be complex
• Efficiently mapped onto TinyOS etc.
• Different semantics Event-driven
• Otherwise, compiled executable will not be
  practically usable
• Versatile
• Applicability to wide range of systems
• Because TML aims to be a common abstract layer
• Mask the complexity
• Because it is the fundamental reason for
  intermediate language

14
TML Sample Code
Shared memory of the node
Private Memory of the token object
Subroutine call / schedule new token
15
Token Machine Language (TML)

• Subroutine calls with return values
• In the DTM model, it would be ideal to exclude
  them to keep the atomic actions small and fast
• Another problem is the DTM model lacks a
  call-stack
• Solution
• Building return handler-calls on top of core TML
  using a continuation passing style (CPS)
  transformation.
• Implicitly split-phase calls

16
Example
Subcall (continuation handler)
Subroutine Call
17
Token Machine Language (TML)

• The Implementation process is bidirectional
• Compiled down to NesC code
• TML is build up by enriching it with features.
• Gradients

18
Evaluation

• Current implementation
• High level simulator
• Compiler targeting NesC/TinyOS Environment
• Comparison with native TinyOS code
• Code size is good
• CPU and RAM usage are bad
• Overhead when running the scheduler
• Unnecessary buffer copying
• Due to no pointer

19
Conclusion

• Important TML qualities
• The atomic action model of concurrency
• Precludes deadlock
• Makes reasoning about timing simple
• Communication is bound to persistent storage
  (tokens)
• Gives us a way to refer to communications that
  have happened through the token they leave behind

20
Questions?