Murat Demirbas

1
Transact A Transactional Programming Framework
for Wireless Sensor/Actor Networks

• Murat Demirbas
• SUNY Buffalo
• CSE Dept.

transactions
WSANs
data-race conditions
optimistic concurrency control
write-all
wireless broadcast
consistency coordination
Multi-robot cooperative control distributed
control
conflict serializability
2
Wireless sensor/actor networks (WSANs)

• Embedded hybrid systems
• PC processors are only 2 of all processors, the
  rest goes to
• Automotive Communications Consumer electronics
  Industrial equipment
• WSNs act as data collection aggregation
  networks
• environmental monitoring, military surveillance
  networks
• WSANs possess actuation capability as well
  applications are
• factory automation process control systems
• vibration control, valve control
• multi-robot cooperative control
• robotic highway safety/construction markers
• automated mobile search surveillance

WSANs
3
WSANs programming challenges

• Consistency and coordination
• In contrast to WSNs, where eventual consistency
  loose synchrony is sufficient for most
  applications and services, distributed control
  coordination are needed for most WSANs
  applications
• Effective management of concurrent execution
• For safety reasons concurrency needs to be tamed
  to prevent unintentional nondeterministic
  executions
• On the other hand, for real-time guarantees
  concurrency needs to be boosted to achieve
  timeliness

data-race conditions
4
Transact A transactional programming framework
for WSANs

• Transact eliminates unintentional
  nondeterministic executions and achieves
  simplicity in reasoning while retaining the
  concurrency of executions
• Conflict serializability any property proven for
  the single threaded coarse-grain executions of
  the system is a property of the concurrent
  fine-grain executions of the system
• Transact enables ease of programming for WSANs
• Transact introduces a novel consistent
  write-all paradigm that enables a node to update
  the state of its neighbors in a consistent and
  simultaneous manner
• Consistent write-all facilitates achieving
  consistency and coordination and may enable
  development of more efficient control and
  coordination programs than possible using
  traditional models

transactions
5
Outline of this talk

• Overview of Transact
• Inner-workings of Transact
• Implementation and simulation results
• Multihop networks extensions

6
Overview of Transact

• Optimistic concurrency control (OCC) idea
• Read Transaction begins by reading values and
  writing to a sandbox
• Validation The database checks if the
  transaction conflicted with any other concurrent
  transaction. If so, the transaction is aborted
  restarted
• Commit Otherwise, the transactions commits
• In Transact, a transaction, an execution of a
  nonlocal method (which requires inter-node
  communication) is structured as readwrite-all
• Each read operation reads variables from some
  nodes in singlehop, and write-all operation
  writes to variables of a set of nodes in
  singlehop
• Read operations are always compatible with each
  other since reads do not change the state, it is
  allowable to swap the order of reads across
  different transactions (and even within the same
  transaction)

optimistic concurrency control
7
Overview of Transact

• A write-all operation may fail to complete when a
  conflict with another transaction is reported
• When a write-all operation fails, the transaction
  aborts without any side-effects
• Since the write-all operation is placed at the
  end of the transaction, if it fails no state is
  changed. An aborted transaction can be retried
  later
• If there are no conflicts reported, write-all
  succeeds by updating the state of the nodes in a
  consistent and simultaneous manner

write-all
8
Challenges opportunities in Transact

• In contrast to database systems, in distributed
  WSANs there is no central database repository or
  arbiter
• the control and sensor variables, on which the
  transactions operate, are maintained
  distributedly over several nodes
• Broadcast communication opens novel ways for
  optimizing the implementation of read and write
  operations
• A broadcast is received by the recipients
  simultaneously
• Broadcast allows snooping
• Property 1 gives us a powerful low-level atomic
  primitive using which we order operations
• We use Property 2, i.e., snooping, for detecting
  conflicts between transactions without the help
  of an arbiter

wireless broadcast
9
Conflicting transactions

• Any two transactions t1 and t2 are conflicting
  iff
• a read-write incompatibility introduces a
  causality from t1 to t2
• and a write-write or a read-write incompatibility
  introduces a causality from t2 to t1

t1.write-all(l.x)
t1.read(l.x)
j
read-write incompat.
write-write incompat.
k
t2.write-all(l.x)
conflict serializability
10
Conflict detection

• To enable decentralized and low-cost detection of
  conflicts, we use nodes to act as proxies for
  detecting incompatibilities between transactions
  by snooping over broadcast messages

l
t1.write-all(l.y)
t2.write-all(l.x,l.y)
j
conflict_msg
k
t1.read(l.x)
t2.write-all(l.x,l.y)
l
conflict serializability
11
Timeline of a transaction
Time-out based commit
conflict_msg
read-request()
write-all()
abort
read-reply
ack
ack
read-reply
ack
ack
Time-out based commit
Timeout-based commit is used for consistency
12
Transact programs

• bool become_leader()
• Xread(.leader)
• if (XØ) then
• return write-all(.leaderID)
• return FAILURE
• bool consensus()
• Xread(.vote)
• if (X1) then
• return write-all(.voteX)
• return FAILURE

• bool recovery_action()
• Xread(.state)
• if (legal(X)) then
• return write-all(.state correct(X))
• return SUCCESS

13
Different flavors of Transact

• Different applications may require different
  levels of timeliness consistency guarantees
  from transactions
• Some applications may require tight consistency
  requirements
• version validation after reprogramming, or
  safety-critical tasks such as regulating valves
  in a chemical factory
• For some applications timeliness may be more
  important than consistency
• feedback-based motion control applications (these
  have built-in resiliency to noise in the system
  due to continuous invocations and feedback)
• We identify four main types of transactions
• complete transactions employ all the mechanisms
• reliable transactions waive the
  conflict-detection mechanism, but may still
  cancel a transaction if write-acks are not
  received from all participants
• ev-reliable (eventually-reliable) forgo the
  transaction cancellation, and replace this with
  re-transmission of the write in case of missing
  write-acks.
• unreliable waive even the write-ack mechanism,
  and perform a bare-bones write operation.

14
Implementation results

• Tmote-invent platform
• 250kbps, CC2420 radio
• With better radio 10 fold improvements possible
• A simple collaborative counting application
• nodes try to increment counters maintained by
  other nodes
• 1st experiment counters initiate transactions at
  the same time
• Complete flavor had 100 success for transaction
  durations gt0.2, 0.8
• Unreliable flavor did not have any success
• 2nd experiment introducing controlled
  phase-shifts between the initiation of
  transactions
• 100 success for complete
• Limited success for unreliable

15
Simulation results
16
Middleware for building Multihop programs

• Transact can be used for efficient realizations
  of high-level programming abstractions, Linda
  virtual node(VN)
• In Linda, coordination among nodes is achieved
  through in, out operations using which tuples can
  be added to or retrieved from a tuplespace shared
  among nodes
• maintaining the reliability and consistency of
  the shared tuplespace to the face of concurrent
  execution of in and out operations at different
  nodes can be achieved via Transact
• VN provides stability and robustness in spite of
  mobility of nodes

Multi-robot cooperative control
17
Related work

• Database transactions are centralized with single
  arbiter
• Software-based transactional memory is limited
  to threads interacting through memory in a single
  process
• Programming abstractions for WSN provide
  loosely-synchronized, eventually consistent view
  of system states
• Seuss programming discipline also provides a
  reduction theorem
• requires a compile-time semantic compatibility
  check to be performed across nodes and allow only
  semantically compatible methods across nodes to
  run concurrently by asserting pre-synchronization
  inserted between incompatible methods
• requires a proof of partial orders on methods at
  the compile-time in order to prevent the case
  where a method can be called malformedly as part
  of its execution

18
Our ongoing work

• Roomba-Create motes running Transact to
  implement multi-robot cooperative control
• A decentralized virtual traffic light
  implementation demo
• Receiver-side collision detection for lightweight
  implementation of Transact
• Binary probing instead of full-fledged read
• Ev-reliable transactions, but conflict-serializabi
  lity is still achievable

19
Concluding remarks

• Transact is a transactional programming framework
  for WSANs
• provides ease of programming and reasoning in
  WSANs without curbing the concurrency of
  execution,
• facilitates achieving consistency and
  coordination the consistent write-all primitive
  may enable development of more efficient control
  coordination programs than possible using
  traditional models
• Future work
• Verification support Transact already provides
  conflict serializability, the burden on the
  verifier is significantly reduced
• Transact patterns programmers can adapt commonly
  occurring patterns for faster development