Murat Demirbas SUNY Buffalo CSE Dept. Transact Transact: A Transactional Programming Framework for Wireless Sensor/Actor Networks optimistic concurrency control consistency & coordination write-all data-race conditions Multi-robot cooperative control distributed control conflict serializability wireless broadcast

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

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 Transact: A transactional programming framework for WSANs TransactTransact 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 TransactTransact enables ease of programming for WSANs  Transact  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

5 Outline of this talk TransactOverview of Transact TransactInner-workings of Transact Implementation and simulation results Multihop networks extensions

6 Transact 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 TransactIn Transact, a transaction, an execution of a nonlocal method (which requires inter-node communication) is structured as read*[write-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 Transact 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 Transact 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 1. A broadcast is received by the recipients simultaneously 2. 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 conflict serializability j k t1.read(l.x) t2.write-all(l.x) t1.write-all(l.x) read-write incompat.write-write incompat.

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 conflict serializability j l l’ k t1.read(l.x) t2.write-all(l.x,l’.y) t1.write-all(l’.y) conflict_msg

11 Timeline of a transaction Time-out based commit Time-out based commit read-request(…) read-reply write-all(…) ack conflict_msg abort ack Timeout-based commit is used for consistency

12 Transact programs bool become_leader(){ X=read(*.leader); if (X=Ø) then return write-all(*.leader=ID); return FAILURE; } bool consensus(){ X=read(*.vote); if (|X|=1) then return write-all(*.vote=X); return FAILURE; } bool recovery_action(){ X=read(*.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 1 st experiment: counters initiate transactions at the same time –Complete flavor had 100% success for transaction durations >0.2, 0.8 –Unreliable flavor did not have any success 2 nd 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 TransactTransact 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-serializability is still achievable

19 Concluding remarks TransactTransact 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  Transact patterns: programmers can adapt commonly occurring patterns for faster development