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
Top Related