Transact A Transactional Transact Programming Framework for Wireless

Transact: A Transactional Transact Programming Framework for Wireless Sensor/Actor Networks Murat Demirbas SUNY Buffalo CSE Dept. data-race cond itions istic trol optim ency con ncurr co conflict serializ ability wri te-a ll wireless broad cast oordinatiioen ontrol &c c at v consistency c er coop l bot lti-ro d contro Mu e ribut

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 2

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 cond itions 3

Transact: A transactional Transact 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 4

Outline of this talk • Overview of Transact • Inner-workings of Transact • Implementation and simulation results • Multihop networks extensions 5

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 Transact 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) istic trol optim ency con 6 ncurr co

Overview of Transact… 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 wri te-a ll 7

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 broad cast 8

Conflicting transactions • Any two transactions t 1 and t 2 are conflicting iff ¾ a read-write incompatibility introduces a causality from t 1 to t 2 ¾ and a write-write or a read-write incompatibility introduces a causality from t 2 to t 1. read(l. x) t 1. write-all(l. x) j read-write incompat. write-write incompat. k t 2. write-all(l. x) conflict serializ ability 9

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’ t 1. write-all(l’. y) j t 2. write-all(l. x, l’. y) conflict_msg t 1. read(l. x) k t 2. write-all(l. x, l’. y) l conflict serializ ability 10

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

Transact programs bool become_leader(){ bool recovery_action(){ X=read(*. leader); if (X=Ø) then return write-all(*. leader=ID); return FAILURE; } X=read(*. state); if (¬legal(X)) then return write-all(*. state= correct(X)); return SUCCESS; } bool consensus(){ X=read(*. vote); if (|X|=1) then return write-all(*. vote=X); return FAILURE; } 12

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. 13

Implementation results • Tmote-invent platform • 250 kbps, CC 2420 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 14

Simulation results 15

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 l tro e con tiv pera coo obot -r Multi 16

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 looselysynchronized, 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 17

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 18

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 19