Murat Demirbas SUNY Buffalo CSE Dept.

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 • Transacteliminates 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 • Transactenables 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 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. 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 inTransact • 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. 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; } Transact programs

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 >0.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-serializability 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