Data Races Atomicity Violations Plus Sequential Programming Bugs! Ordering Bugs Misplaced Synchronization • Testing currently a major challenge 2 Go Huskies! Monday, May 28, 2012
Data Races Atomicity Violations Plus Sequential Programming Bugs! Ordering Bugs Misplaced Synchronization • Testing currently a major challenge • Need tools for bug detection 2 Go Huskies! Monday, May 28, 2012
Data Races Atomicity Violations Plus Sequential Programming Bugs! Ordering Bugs Misplaced Synchronization • Testing currently a major challenge • Need tools for bug detection • Need to survive hard to detect bugs 2 Go Huskies! Monday, May 28, 2012
atomicity violations are common and hard to debug • With unrelated goals, systems supporting implicit atomicity were developed • Implicit Atomicity has an interesting effect on atomicity violations 3 Monday, May 28, 2012
atomicity violations are common and hard to debug • With unrelated goals, systems supporting implicit atomicity were developed • Implicit Atomicity has an interesting effect on atomicity violations •Contributions: • We analyze the interaction of atomicity violations and implicit atomicity • We propose Atom-Aid which carefully controls memory interleaving to detect and survive atomicity violation bugs • We evaluate Atom-Aid with benchmarks including several real applications • Atom-Aid can report bugs to developers so they can be fixed 3 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; What if this happens?! int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y100 T1: Deposit(50); T2: Deposit(50); Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y100 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y150 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y150 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y150 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y100 Y150 T1: Deposit(50); T2: Deposit(50); bal Y150 bal Y150 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y150 Y150 T1: Deposit(50); T2: Deposit(50); bal Y150 bal Y150 Monday, May 28, 2012
bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Y150 Y150 Both threads think the balance is Y150, but it should be Y200!! T1: Deposit(50); T2: Deposit(50); Monday, May 28, 2012
and write_balance can be interleaved, but should be atomic, Deposit has an atomicity violation 5 int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Monday, May 28, 2012
and write_balance can be interleaved, but should be atomic, Deposit has an atomicity violation 5 int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; •Certain dynamic interleavings of Deposit result in a semantic inconsistency •These interleavings are called unserializable interleavings •If atomicity violations are unserializably interleaved, bug behavior occurs! int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Monday, May 28, 2012
and write_balance can be interleaved, but should be atomic, Deposit has an atomicity violation In a ‘08 study by Lu, et al, more than 2/3 of non-deadlocking bugs were atomicity violations 5 int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; •Certain dynamic interleavings of Deposit result in a semantic inconsistency •These interleavings are called unserializable interleavings •If atomicity violations are unserializably interleaved, bug behavior occurs! int bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Monday, May 28, 2012
Read d Write b Read a Write b T1 T2 7 •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation •(Think transactions) Monday, May 28, 2012
Read d Write b Read a Write b Fewer opportunities for unserializable interleavings to occur T1 T2 •Interleaving can only occur at chunk boundaries 7 •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation •(Think transactions) Monday, May 28, 2012
Read d Write b Read a Write b T1 T2 •Interleaving can only occur at chunk boundaries •Chunk size and boundaries can be adjusted arbitrarily 7 •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation •(Think transactions) Monday, May 28, 2012
Read d Write b Read a Write b T1 T2 •Interleaving can only occur at chunk boundaries •Chunk size and boundaries can be adjusted arbitrarily •Interleaving can be changed, and memory semantics preserved 7 •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation •(Think transactions) Monday, May 28, 2012
Read d Write b Read a Write b T1 T2 •Interleaving can only occur at chunk boundaries •Chunk size and boundaries can be adjusted arbitrarily •Interleaving can be changed, and memory semantics preserved 7 •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation •(Think transactions) Many recent Implicit Atomicity proposals: BulkSC, Implicit Transactions, ASO, ... Monday, May 28, 2012
Hidden violations execute atomically read_balance write_balance write_balance read_balance • Atomicity violations can be exposed •Atomicity violations can be hidden •Exposed violations may manifest themselves if unserializably interleaved •If a violation is hidden survival is guaranteed 9 Monday, May 28, 2012
Hidden violations execute atomically read_balance write_balance write_balance read_balance • Atomicity violations can be exposed •Atomicity violations can be hidden •Exposed violations may manifest themselves if unserializably interleaved •If a violation is hidden survival is guaranteed 9 Implicit Atomicity Naturally Hides Atomicity Violations Monday, May 28, 2012
chunk Begin chunk closely to beginning of violation •Atom-Aid survives even more violations by dynamically adjusting chunks 12 Hidden! Monday, May 28, 2012
chunk Begin chunk closely to beginning of violation •Atom-Aid survives even more violations by dynamically adjusting chunks •Atom-Aid infers where atomic regions in an execution should be 12 Hidden! Monday, May 28, 2012
in violations T1 T2 Atom-Aid Monitors an address, A, if: 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A 3.The accesses are potentially unserializable read_balance write_balance read_balance write_balance 13 Monday, May 28, 2012
in violations T1 T2 Atom-Aid Monitors an address, A, if: 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A 3.The accesses are potentially unserializable read_balance write_balance read_balance write_balance 13 Monday, May 28, 2012
in violations T1 T2 Atom-Aid Monitors an address, A, if: 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A 3.The accesses are potentially unserializable read_balance write_balance read_balance write_balance 13 Monday, May 28, 2012
in violations T1 T2 Atom-Aid Monitors an address, A, if: 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A 3.The accesses are potentially unserializable read_balance write_balance read_balance write_balance Rd Wr Wr ? 13 Monday, May 28, 2012
in violations T1 T2 Atom-Aid Monitors an address, A, if: 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A 3.The accesses are potentially unserializable read_balance write_balance read_balance write_balance Begin Monitoring Dangerous Address! 13 Monday, May 28, 2012
boundary before dangerous accesses •Conservatively prevents potentially unserializable interleavings •Atom-Aid monitors potential unserializable interleavings •Dangerous addresses can be observed without a violation necessarily occurring 14 write_balance read_balance write_balance Atom-Aid can detect atomicity violations before they manifest themselves and prevent them from occuring Monday, May 28, 2012
operations performed with signatures •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 •Atom-Aid leverages bookkeeping and communication for detection •Additional signatures efficiently maintain memory access history 15 Monday, May 28, 2012
Section 5.2 in the paper for more info •Simulated real, unmodified applications •Simulated representative bug kernels extracted from real software and prior work •Simulations using PIN binary instrumentation framework 17 Monday, May 28, 2012
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 0 25 50 75 100 Apache MySQL XMMS Natural Hiding Active Hiding Percent of Violations Hidden 19 Monday, May 28, 2012
Urbana-Champagne Invariant based detection of Atomicity Violations SVD - Xu, et al - Univ. of Wisconsin, Madison Fully automated serializability checking of atomic regions 20 ASPLOS ‘06 PLDI ‘05 Monday, May 28, 2012
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 21 Monday, May 28, 2012
sequential execution Read ctr Write ctr Write ctr •If Atomicity Violation is unserializably interleaved, atomicity violations manifests itself. say “uninterleaved” execution this list is exhaustive (in the one-variable case) 23 Monday, May 28, 2012
sequential execution Read ctr Write ctr Write ctr R R W W R W W W R •If Atomicity Violation is unserializably interleaved, atomicity violations manifests itself. •There are several cases of unserializable interleaving say “uninterleaved” execution this list is exhaustive (in the one-variable case) 23 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 •Data Races are accesses to shared data without synchronization mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 •Data Races are accesses to shared data without synchronization mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 •Data Races are accesses to shared data without synchronization •Atomicity Violations may exist in race-free programs! mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 •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 mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
tmp++; lock(L); ctr = tmp; unlock(L); T1 lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); T2 Violations manifest themselves when unserializable interleavings occur •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 mention what the correct version of this program is anywhere between the two critical sections 24 Monday, May 28, 2012
violation is exposed the bug may occur if a certain interleaving occurs Pinterleaved -> Pbadinterleaving natural hiding - there is a chance operations will naturally be atomic hence natural hiding ditch script 25 Monday, May 28, 2012
violation is exposed the bug may occur if a certain interleaving occurs •If Pexposed could be reduced to 0 the violation would never manifest itself Pinterleaved -> Pbadinterleaving natural hiding - there is a chance operations will naturally be atomic hence natural hiding ditch script 25 Monday, May 28, 2012
violation is exposed the bug may occur if a certain interleaving occurs •If Pexposed could be reduced to 0 the violation would never manifest itself •Implicit Atomicity decreases Pexposed so some violations are naturally hidden Pinterleaved -> Pbadinterleaving natural hiding - there is a chance operations will naturally be atomic hence natural hiding ditch script 25 Monday, May 28, 2012
Read ctr Write ctr Read ctr Write ctr •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks are not a programming construct •Chunks execute atomically and in isolation { { Chunks Possible Interleavings 26 Monday, May 28, 2012
Read ctr Write ctr Read ctr Write ctr Many recent Implicit Atomicity proposals: BulkSC, Implicit Transactions, ASO, ... •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks are not a programming construct •Chunks execute atomically and in isolation { { Chunks Possible Interleavings 26 Monday, May 28, 2012