Transact: A Transactional
Programming Framework for
Wireless Sensor/Actor Networks
Murat Demirbas
SUNY Buffalo
CSE Dept.
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
3
Transact: A transactional
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
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)
6
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
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
8
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.read(l.x)
t1.write-all(l.x)
j
read-write incompat.
write-write incompat.
k
t2.write-all(l.x)
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’
t1.write-all(l’.y)
j
t2.write-all(l.x,l’.y)
conflict_msg
t1.read(l.x)
k
t2.write-all(l.x,l’.y)
l
10
Timeline of a transaction
Time-out based
commit
read-request(…)
write-all(…) conflict_msg
abort
read-reply
ack
ack
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
• 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
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
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