Atom-Aid: Detecting and Surviving Atomicity Violations

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! Ordering Bugs Atomicity Violations Livelocks Misplaced Synchronization Deadlocks Data Races Go Huskies! Plus Sequential Programming Bugs! • Testing currently a major challenge • Need tools for bug detection • Need to survivehard to detect bugs

3. Observations and Our Contribution • Observations: • Prior work showsthat 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

4. 1. Atomicity Violations

5. Account.Deposit(amount){ Account.Deposit(amount){ int bal= read_balance(); int bal = read_balance(); bal += amount; bal += amount; write_balance(bal); write_balance(bal); } } Y50 Y50 An Atomicity Violation is a Hard Concurrency Bug Y150 Y100 Y100 Y150 T1: Deposit(50); T2: Deposit(50); What if this happens?! • Becauseread_balance and write_balancecan be interleaved, but should be atomic, Deposit has an atomicity violation bal Y100 bal Y150 bal Y100 bal Y150 • 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! Both threads think the balance is Y150, but it should be Y200!! In a ‘08 study by Lu, et al, more than 2/3 of non-deadlocking bugs were atomicity violations

6. 2.Implicit Atomicity

7. { Chunks { Fewer opportunities for unserializable interleavings to occur Implicit Atomicity T1 T2 • Implicit atomicity arbitrarily groups instructions into “chunks” Read a Read a • Chunks execute atomically and in isolation • (Think transactions) Write b Write c Read c Read d • Interleaving can only occur at chunk boundaries Write b Write b • Chunk size and boundaries can be adjusted arbitrarily • Interleaving can be changed, and memory semantics preserved Many recent Implicit Atomicity proposals: BulkSC, Implicit Transactions, ASO, ...

8. 3.What Happens When They Get Together

9. Exposed violations can be interleaved Hidden violations execute atomically Atomicity Violations and Implicit Atomicity • Atomicity violations can be exposed • Atomicity violations can be hidden read_balance Implicit Atomicity Naturally Hides Atomicity Violations read_balance write_balance write_balance • Exposed violations may manifest themselves if unserializably interleaved • If a violation is hidden survival is guaranteed reminder: same example clean this up.

10. Natural Hiding Percent of Violations Hidden Chunk Size Implicit Atomicity alone survives a majority violations for these applications

11. Can we do better?

12. Exposed! Hidden! Actively fit violation in only one chunk Begin chunk closely to beginning of violation Smart Chunking • Atom-Aid survives even more violations by dynamically adjusting chunks read_balance • Atom-Aid infers where atomic regions in an execution should be write_balance

13. Rd ? Wr Wr Detecting Potential Atomicity Violations • Atom-Aid monitors dangerous addresses potentially involved in violations T2 T1 Atom-Aid Monitors an address, A, if: read_balance read_balance 1.A thread makes 2 “nearby” accesses to A 2.Another thread has “recently” accessed A write_balance write_balance 3.The accesses are potentially unserializable Begin Monitoring Dangerous Address!

14. Atom-Aid Actively Hides Atomicity Violations • Atom-Aid monitors potential unserializable interleavings • Dangerous addresses can be observed without a violation necessarily occurring read_balance Atom-Aid can detect atomicity violations before they manifest themselves and prevent them from occuring write_balance write_balance • Smart chunking inserts a chunk boundary before dangerousaccesses • Conservatively prevents potentially unserializable interleavings

15. Implementing Atom-Aid chose to use BulkSC like system for impl. atom. Bulk SC uses sigs, which are convenient because it makes keeping sets cheap, and communication cheap Extra sigs to keep history • 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 • Efficientcommunication 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

16. Evaluation

17. Evaluating Atom-Aid • Simulated representative bug kernels extracted from real software and prior work java.lang.StringBuffer Shared work queue • Simulated real, unmodified applications MySQL Apache XMMS • Simulations using PIN binary instrumentation framework See Section 5.2 in the paper for more info

18. Active Hiding Chunk Size (insns.) ugly keynote import not “anomalous” highlight apache, then explain Percent of Violations Hidden Atom-Aid hides virtually 100% of instances of the violations in these applications

19. Hiding Bugs in Full Applications • Atom-Aid hides most instancesof the violations in the unmodified applications we evaluated • Atom-Aid’s performance impact is negligible, on top of performance impact of implicit atomicity Percent of Violations Hidden • Atom-Aid requires no modifications to software and no code annotations

20. 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

21. 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

22. 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

23. W W R R W W R R W say “uninterleaved” execution this list is exhaustive (in the one-variable case) Serializability An interleaving is unserializable if there is no equivalent sequential execution Readctr • If Atomicity Violation is unserializably interleaved, atomicity violations manifests itself. Writectr • There are several cases of unserializable interleaving Writectr

24. lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); Atomicity Violation != Data Race mention what the correct version of this program is anywhere between the two critical sections T1 T2 • Data Races are accesses to shared data without synchronization • Atomicity Violations may exist in race-freeprograms! • Atomicity Violations result from false assumptions about atomicity lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); Violations manifest themselves when unserializable interleavings occur

25. Probabilistic Survival Pinterleaved -> Pbadinterleaving natural hiding - there is a chance operations will naturally be atomic hence natural hiding ditch script • If a violation is exposed the bug may occur if a certain interleaving occurs Pmanifestation = Pexposedx Pbad interleaving • If Pexposed could be reduced to 0 the violation would never manifest itself • If a violation is hidden, the bug is guaranteed not to occur • Implicit Atomicity decreases Pexposed so some violations are naturally hidden

26. Read ctr Read ctr Read ctr Read ctr lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); lock(L); tmp = ctr; unlock(L); tmp++; lock(L); ctr = tmp; unlock(L); Read ctr Read ctr Read ctr Read ctr Read ctr Write ctr Write ctr Read ctr Write ctr Write ctr Write ctr Write ctr Write ctr Read ctr Read ctr Write ctr Write ctr Write ctr Write ctr Write ctr Implicit Atomicity add bullet saying chunks execute atomically and in isolation Atomic Sequence Ordering weird: rectangles -- what are they chunky interleavings last, move them to be grouped chunky ones are legal, disallow other ones { T1 T2 • Traditional architectures permit many fine-grained interleavings Chunks { Possible Interleavings • Implicit atomicity arbitrarily groups instructions into “chunks” • Chunks execute atomically and in isolation • Chunks are not a programming construct Many recent Implicit Atomicity proposals: BulkSC, Implicit Transactions, ASO, ...