Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Atom-Aid at ISCA 2008

Atom-Aid at ISCA 2008

This is a talk I gave at ISCA 2008 on Atom-Aid, an new computer architecture design for avoiding failures related to concurrency bugs.

Brandon Lucia

May 28, 2012
Tweet

More Decks by Brandon Lucia

Other Decks in Research

Transcript

  1. Atom-Aid: Detecting and Surviving Atomicity Violations Brandon Lucia†, Joseph Devietti†,

    Karin Strauss†‡, Luis Ceze† ISCA 2008, Beijing, China †University of Washington ‡Advanced Micro Devices, Inc 1 Monday, May 28, 2012
  2. Motivation • Shared memory parallel programming is hard! Deadlocks Livelocks

    Data Races Atomicity Violations Plus Sequential Programming Bugs! Ordering Bugs Misplaced Synchronization 2 Go Huskies! Monday, May 28, 2012
  3. Motivation • Shared memory parallel programming is hard! Deadlocks Livelocks

    Data Races Atomicity Violations Plus Sequential Programming Bugs! Ordering Bugs Misplaced Synchronization • Testing currently a major challenge 2 Go Huskies! Monday, May 28, 2012
  4. Motivation • Shared memory parallel programming is hard! Deadlocks Livelocks

    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
  5. Motivation • Shared memory parallel programming is hard! Deadlocks Livelocks

    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
  6. Observations and Our Contribution •Observations: • Prior work shows that

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

    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
  8. An Atomicity Violation is a Hard Concurrency Bug 5 int

    bal = read_balance(); Account.Deposit(amount){ } write_balance(bal); bal += amount; Monday, May 28, 2012
  9. An Atomicity Violation is a Hard Concurrency Bug 5 int

    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
  10. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y100 T1: Deposit(50); T2: Deposit(50); Monday, May 28, 2012
  11. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 Monday, May 28, 2012
  12. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y100 Monday, May 28, 2012
  13. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y100 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y150 Monday, May 28, 2012
  14. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y150 T1: Deposit(50); T2: Deposit(50); bal Y100 bal Y150 Monday, May 28, 2012
  15. An Atomicity Violation is a Hard Concurrency Bug 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; Y100 Y150 T1: Deposit(50); T2: Deposit(50); bal Y150 bal Y150 Monday, May 28, 2012
  16. An Atomicity Violation is a Hard Concurrency Bug 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; Y150 Y150 T1: Deposit(50); T2: Deposit(50); bal Y150 bal Y150 Monday, May 28, 2012
  17. An Atomicity Violation is a Hard Concurrency Bug 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; Y150 Y150 Both threads think the balance is Y150, but it should be Y200!! T1: Deposit(50); T2: Deposit(50); Monday, May 28, 2012
  18. An Atomicity Violation is a Hard Concurrency Bug •Because read_balance

    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
  19. An Atomicity Violation is a Hard Concurrency Bug •Because read_balance

    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
  20. An Atomicity Violation is a Hard Concurrency Bug •Because read_balance

    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
  21. Implicit Atomicity Read c Write b Read a Write c

    Read d Write b Read a Write b T1 T2 7 Monday, May 28, 2012
  22. Implicit Atomicity Read c Write b Read a Write c

    Read d Write b Read a Write b T1 T2 7 •Implicit atomicity arbitrarily groups instructions into “chunks” Monday, May 28, 2012
  23. Implicit Atomicity Read c Write b Read a Write c

    Read d Write b Read a Write b T1 T2 7 •Implicit atomicity arbitrarily groups instructions into “chunks” { Chunks { Monday, May 28, 2012
  24. Implicit Atomicity Read c Write b Read a Write c

    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
  25. Implicit Atomicity Read c Write b Read a Write c

    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
  26. Implicit Atomicity Read c Write b Read a Write c

    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
  27. Implicit Atomicity Read c Write b Read a Write c

    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
  28. Implicit Atomicity Read c Write b Read a Write c

    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
  29. Atomicity Violations and Implicit Atomicity Exposed violations can be interleaved

    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
  30. Atomicity Violations and Implicit Atomicity Exposed violations can be interleaved

    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
  31. Natural Hiding Implicit Atomicity alone survives a majority violations for

    these applications BankAccount MySQL-extract LogProc&Sweep StringBuffer CircularList Apache-extract BankAccount2 LogProc&Sweep2 CircularList2 Chunk Size Percent of Violations Hidden 10 Monday, May 28, 2012
  32. Natural Hiding Implicit Atomicity alone survives a majority violations for

    these applications 750 1000 1500 2000 4000 6000 8000 0 25 50 75 100 BankAccount MySQL-extract LogProc&Sweep StringBuffer CircularList Apache-extract BankAccount2 LogProc&Sweep2 CircularList2 Chunk Size Percent of Violations Hidden 10 Monday, May 28, 2012
  33. Natural Hiding Implicit Atomicity alone survives a majority violations for

    these applications 750 1000 1500 2000 4000 6000 8000 0 25 50 75 100 BankAccount MySQL-extract LogProc&Sweep StringBuffer CircularList Apache-extract BankAccount2 LogProc&Sweep2 CircularList2 Chunk Size Percent of Violations Hidden 10 Monday, May 28, 2012
  34. Natural Hiding Implicit Atomicity alone survives a majority violations for

    these applications 750 1000 1500 2000 4000 6000 8000 0 25 50 75 100 BankAccount MySQL-extract LogProc&Sweep StringBuffer CircularList Apache-extract BankAccount2 LogProc&Sweep2 CircularList2 Chunk Size Percent of Violations Hidden 10 Monday, May 28, 2012
  35. Smart Chunking write_balance read_balance •Atom-Aid survives even more violations by

    dynamically adjusting chunks 12 Exposed! Monday, May 28, 2012
  36. Smart Chunking write_balance read_balance Actively fit violation in only one

    chunk Begin chunk closely to beginning of violation •Atom-Aid survives even more violations by dynamically adjusting chunks 12 Hidden! Monday, May 28, 2012
  37. Smart Chunking write_balance read_balance Actively fit violation in only one

    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
  38. Detecting Potential Atomicity Violations •Atom-Aid monitors dangerous addresses potentially involved

    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
  39. Detecting Potential Atomicity Violations •Atom-Aid monitors dangerous addresses potentially involved

    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
  40. Detecting Potential Atomicity Violations •Atom-Aid monitors dangerous addresses potentially involved

    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
  41. Detecting Potential Atomicity Violations •Atom-Aid monitors dangerous addresses potentially involved

    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
  42. Detecting Potential Atomicity Violations •Atom-Aid monitors dangerous addresses potentially involved

    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
  43. Atom-Aid Actively Hides Atomicity Violations •Atom-Aid monitors potential unserializable interleavings

    •Dangerous addresses can be observed without a violation necessarily occurring 14 write_balance read_balance write_balance Monday, May 28, 2012
  44. Atom-Aid Actively Hides Atomicity Violations •Smart chunking inserts a chunk

    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 Monday, May 28, 2012
  45. Atom-Aid Actively Hides Atomicity Violations •Smart chunking inserts a chunk

    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
  46. Implementing Atom-Aid Details in the paper •Efficient communication and set

    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
  47. Evaluating Atom-Aid MySQL Apache XMMS java.lang.StringBuffer Shared work queue See

    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
  48. Active Hiding Atom-Aid hides virtually 100% of instances of the

    violations in these applications 0 25 50 75 100 BankAccount M ySQ L-extract LogProc&Sweep StringBuffer C ircularList Apache-extract BankAccount2 LogProc&Sweep2 C ircularList2 750 1000 1500 2000 4000 6000 8000 Percent of Violations Hidden Chunk Size (insns.) 18 Monday, May 28, 2012
  49. Hiding Bugs in Full Applications •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 0 25 50 75 100 Apache MySQL XMMS Natural Hiding Active Hiding Percent of Violations Hidden 19 Monday, May 28, 2012
  50. Inspirations AVIO - Lu, et al - Univ. of Illinois,

    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
  51. 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 21 Monday, May 28, 2012
  52. Atom-Aid: Detecting and Surviving Atomicity Violations Brandon Lucia†, Joseph Devietti†,

    Karin Strauss†‡, Luis Ceze† ISCA 2008, Beijing, China †University of Washington ‡Advanced Micro Devices, Inc 22 Monday, May 28, 2012
  53. Serializability An interleaving is unserializable if there is no equivalent

    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
  54. Serializability An interleaving is unserializable if there is no equivalent

    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
  55. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  56. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  57. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  58. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  59. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  60. Atomicity Violation != Data Race lock(L); tmp = ctr; unlock(L);

    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
  61. Probabilistic Survival Pmanifestation = Pexposed x Pbad interleaving •If a

    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
  62. Probabilistic Survival Pmanifestation = Pexposed x Pbad interleaving •If a

    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
  63. Probabilistic Survival Pmanifestation = Pexposed x Pbad interleaving •If a

    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
  64. Implicit Atomicity •Traditional architectures permit many fine-grained interleavings 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); T1 T2 26 Monday, May 28, 2012
  65. Implicit Atomicity Read ctr Read ctr Write ctr Write ctr

    •Traditional architectures permit many fine-grained interleavings 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); T1 T2 Possible Interleavings 26 Monday, May 28, 2012
  66. Implicit Atomicity Read ctr Read ctr Write ctr Write ctr

    Read ctr Read ctr Write ctr Write ctr •Traditional architectures permit many fine-grained interleavings 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); T1 T2 Possible Interleavings 26 Monday, May 28, 2012
  67. Implicit Atomicity Read ctr Read ctr Write ctr Write ctr

    Read ctr Read ctr Write ctr Write ctr Read ctr Read ctr Write ctr Write ctr •Traditional architectures permit many fine-grained interleavings 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); T1 T2 Possible Interleavings 26 Monday, May 28, 2012
  68. Implicit Atomicity Read ctr Read ctr Write ctr Write ctr

    Read ctr Read ctr Write ctr Write ctr Read ctr Read ctr Write ctr Write ctr Read ctr Write ctr Read ctr Write ctr •Traditional architectures permit many fine-grained interleavings 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); T1 T2 Possible Interleavings 26 Monday, May 28, 2012
  69. Implicit Atomicity Read ctr Write ctr Read ctr Write ctr

    Read ctr Write ctr Read ctr Write ctr •Implicit atomicity arbitrarily groups instructions into “chunks” { { Chunks Possible Interleavings 26 Monday, May 28, 2012
  70. Implicit Atomicity Read ctr Write ctr Read ctr Write ctr

    Read ctr Write ctr Read ctr Write ctr •Implicit atomicity arbitrarily groups instructions into “chunks” •Chunks execute atomically and in isolation { { Chunks Possible Interleavings 26 Monday, May 28, 2012
  71. Implicit Atomicity Read ctr Write ctr Read ctr Write ctr

    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
  72. Implicit Atomicity Read ctr Write ctr Read ctr Write ctr

    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