Transcript Atom-Aid: Detecting and Surviving Atomicity Violations Brandon Lucia†, Joseph Devietti†, Karin Strauss†‡, Luis Ceze† †University of Washington ‡Advanced Micro Devices, Inc ISCA 2008, Beijing, China.

1
Atom-Aid:
Detecting and Surviving
Atomicity Violations
Brandon Lucia†, Joseph Devietti†, Karin Strauss†‡, Luis
Ceze†
†University
of Washington
‡Advanced Micro Devices, Inc
ISCA 2008, Beijing, China
2
Motivation
• Shared memory parallel programming
is hard!
•
•
•
Plus Sequential Programming Bugs!
Testing currently a major challenge
Need tools for bug detection
Need to survive hard to detect bugs
4
Observations and Our
• Observations: Contribution
1. Prior work shows that atomicity violations are common and hard to
debug
2. With unrelated goals, systems supporting implicit atomicity were
developed
3. Implicit Atomicity has an interesting effect on atomicity violations
• Contributions:
1. We analyze the interaction of atomicity violations and implicit atomicity
2. We propose Atom-Aid which carefully controls memory interleaving to
detect and survive atomicity violation bugs
3. We evaluate Atom-Aid with benchmarks including several real
applications
4. Atom-Aid can report bugs to developers so they can be fixed
1. Atomicity Violations
6
An Atomicity Violation is
a Hard
Concurrency
Y100
Y150
Y150
Y100
Bug
Y50
T1: Deposit(50);
Account.Deposit(amount){
int bal = read_balance();
Because
read_balance and write_balance can be
bal += amount;
write_balance(bal);
atomic,
Deposit has an atomicity violation
}
•
Y50
What if this
T2: Deposit(50);
happens?!
Account.Deposit(amount){
int bal = read_balance();
interleaved,
but should be
bal += amount;
write_balance(bal);
}
•Certain
interleavings
of Deposit
result
in abut
semantic
inconsistency
bal dynamic
Both
threads
think
the
balance
is
Y150,
it
should
be
bal
bal
•These
are called unserializable interleavings
Y150 interleavings
Y200!!
Y100
Y150
•IfY100
atomicity violations are unserializably interleaved, bug behavior
occurs!
In a ‘08 study by Lu, et al, more than 2/3 of non-deadlocking bugs were atomicity
violations
2.Implicit Atomicity
8
Implicit Atomicity
•Implicit atomicity arbitrarily
groups instructions into
“chunks”
T1
T2
Read a
Read a
Write b
Write c
Read c
Read d
Write b
Write b
•Chunks execute atomically
Chunks
and in isolation
•(Think transactions)
•Interleaving can only occur at
chunk boundaries
•Chunk size and boundaries can
be adjusted arbitrarily
•Interleaving can be changed, and
memory semantics preserved
Many
Fewer
recent
opportunities
Implicit Atomicity
for
unserializable
proposals: BulkSC,
interleavings
Implicitto
Transactions,
occur ASO, ...
3.What Happens When
They Get Together
10
Atomicity Violations
and Implicit Atomicity
•Atomicity violations can be
exposed
•Atomicity violations can be hidden
Exposed violations
read_balance
Implicit
Atomicity
Naturally
can be interleaved
Hidden violations
Hides Atomicity
Violations
execute atomically
read_balance
•Exposed violations
may manifest
themselves if
unserializably
interleaved
write_balance
write_balance
•If a violation is
hidden survival is
guaranteed
11
Percent of Violations Hidden
Natural Hiding
Chunk Size
Implicit Atomicity alone survives a majority violations for these applications
Can we do better?
13
Smart Chunking
Begin chunk closely to
beginning of violation
•Atom-Aid survives even more
violations by dynamically adjusting
chunks
read_balance
Hidden!
Exposed!
•Atom-Aid infers where atomic regions
in an execution should be
Actively fit violation in
only one chunk
write_balance
14
Detecting Potential
Atomicity Violations
•Atom-Aid monitors dangerous addresses potentially involved in
violations
T2
T1
Atom-Aid Monitors an address, A, if:
1.A thread makes 2 “nearby” accesses to
A
Rd
read_balance
Wr
Wr
?
read_balance
2.Another thread has “recently” accessed
A
write_balance
3.The accesses are potentially
unserializable
Begin Monitoring Dangerous Address!
write_balance
15
Atom-Aid Actively
Hides Atomicity
Violations
•Atom-Aid monitors potential
unserializable interleavings
•Dangerous addresses can be
observed without a violation necessarily
occurring
Atom-Aid can detect atomicity
read_balance
violations before they
manifest themselves and prevent them from occuring
write_balance
•Smart chunking inserts a chunk
boundary before dangerous
accesses
•Conservatively prevents potentially
unserializable interleavings
write_balance
16
Implementing AtomAid
•This work uses a BulkSC-like system for Implicit Atomicity
•BulkSC provides sequential consistency at a coarse grain using
signatures
•Each chunk maintains a read and write signature
•Efficient communication and set operations performed with
signatures
•Atom-Aid leverages bookkeeping and communication for
detection
•Additional signatures efficiently maintain memory access
history
Details in the paper
Evaluation
18
Evaluating Atom-Aid
•Simulated representative
bug kernels extracted from
real software and prior
work
java.lang.StringBuf
fer
Shared work
queue
•Simulated real,
unmodified applications
•Simulations using PIN
MySQL
Apache
binary instrumentation
framework
See Section 5.2 in the paper for more info
XMMS
19
Active Hiding
Percent of Violations Hidden
Chunk Size (insns.)
Atom-Aid hides virtually 100% of instances of the violations in these
applications
20
Hiding Bugs in Full
Applications
Percent of Violations Hidden
•Atom-Aid hides most instances of the
violations in the unmodified applications we
evaluated
•Atom-Aid’s performance impact is
negligible, on top of performance impact of
implicit atomicity
•Atom-Aid requires no modifications to
software and no code annotations
21
Inspirations
AVIO - Lu, et al - Univ. of Illinois, Urbana-Champagne
Invariant based detection of Atomicity Violations
ASPLOS ‘06
SVD - Xu, et al - Univ. of Wisconsin, Madison
Fully automated serializability checking of atomic
regions
PLDI ‘05
22
•
•
•
•
Atom-Aid
Atomicity Violations are a challenging, subtle bug
Implicity Atomicity can Naturally Hide some atomicity
violations
Atom-Aid uses Smart Chunking to Actively Hide
nearly all instances of atomicity violations in
applications evaluated
Atom-Aid reports bugs back to programmers to aid in
development, testing and debugging
23
Atom-Aid:
Detecting and Surviving
Atomicity Violations
Brandon Lucia†, Joseph Devietti†, Karin Strauss†‡, Luis
Ceze†
†University
of Washington
‡Advanced Micro Devices, Inc
ISCA 2008, Beijing, China
24
say “uninterleaved” execution
this list is exhaustive (in the one-variable case)
Serializability
An interleaving is unserializable if there is no equivalent sequential
execution
•If Atomicity Violation is
Read ctr
unserializably interleaved,
atomicity violations manifests
itself.
R
W
W
W
W
R
R
R
W
Write ctr
•There are several cases of
unserializable interleaving
Write ctr
25
Atomicity Violation != Data
Race
mention what the correct version of this program is
anywhere between the two critical sections
•Data Races are accesses to
shared data without
synchronization
•Atomicity Violations may exist in
race-free programs!
•Atomicity Violations result from
false assumptions about
atomicity
T1
lock(L);
tmp = ctr;
unlock(L);
tmp++;
lock(L);
ctr = tmp;
unlock(L);
T2
lock(L);
tmp = ctr;
unlock(L);
tmp++;
lock(L);
ctr = tmp;
unlock(L);
Violations manifest themselves when unserializable interleavings occur
27
Probabilistic Survival
Pinterleaved -> Pbadinterleaving
natural hiding - there is a chance operations will
naturally be atomic hence natural hiding
•If a violation is exposed the bug may occur if aditchcertain
interleaving occurs
script
Pmanifestation = Pexposed x Pbad
interleaving
•If Pexposed could be reduced to 0 the violation would never manifest itself
•Implicit Atomicity decreases Pexposed so some violations are naturally
hidden
28
Implicit Atomicity
T1
•Traditional architectures
permit many
fine-grained
Chunks
interleavings
lock(L);
tmp = ctr;
Readunlock(L);
ctr
groups instructions into
“chunks”
•Chunks execute atomically
and in isolation
programming construct
Read ctr
tmp++;
lock(L);
ctr = tmp;
unlock(L);
lock(L);
ctr = tmp;
unlock(L);
Write ctr
Possible Interleavings
Read ctr
Read ctr
Read ctr
Read ctr
Read ctr
Read ctr
Read ctr
Write ctr
Read ctr
Write ctr
Write ctr
•Chunks are not a
lock(L);
tmp = ctr;
unlock(L);
tmp++;
Write ctr
•Implicit atomicity arbitrarily
T2
Write ctr
Write ctr
Write ctr
Read ctr
Read ctr
Many recent Implicit Atomicity proposals:
Write ctr
Write ctr
Write ctr
Write ctr
BulkSC, Implicit Transactions, ASO, ...