Murat Demirbas

SUNY Buffalo

CSE Dept.

TransactTransact: A Transactional Programming Framework for Wireless Sensor/Actor Networks

optimisticoptimistic

concurrency concurrency control

control

consistency & consistency & coordinationcoordination

write-allwrite-all

data-race conditions

Multi-robot cooperative control

distributed controlconflict 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

TransactTransact: 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

TransactTransact 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

• Overview of TransactTransact

• Inner-workings of TransactTransact

• Implementation and simulation results

• Multihop networks extensions

6

Overview of TransactTransact

• 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 TransactTransact, 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)

optimisticoptimistic

concurrency concurrency control

control

7

Overview of TransactTransact…

• 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-allwrite-all

8

Challenges & opportunities in TransactTransact

• 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)

t2.write-all(l.x,l’.y)t1.write-all(l’.y)

conflict_msg

11

Timeline of a transaction

Time-out basedcommit

Time-out basedcommit

read-request(…)read-reply

read-reply

write-all(…)ack

ack

conflict_msgabort

ackack

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

• 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

• 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

TransactTransact patterns: programmers can adapt commonly occurring patterns for faster development