Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs Stephen Freund Williams College Cormac Flanagan University of California, Santa Cruz

2 class Account { private int balance = 0; public read() { int r; synchronized(this) { r = balance; } return r; } Race-Free Bank Account public void deposit(int n) { int r = read(); synchronized(this) { balance = r + n; }  Race-freedom is not sufficient other threads can update balance

3 class Account { private int balance = 0; public read() { int r; synchronized(this) { r = balance; } return r; } Fixed Bank Account public void deposit(int n) { synchronized(this) { int r = balance; balance = r + n; }

4 class Account { private int balance = 0; public read() { return balance; } Optimized Bank Account public void deposit(int n) { synchronized(this) { int r = balance; balance = r + n; }  Race-freedom is not necessary

5 Race-Freedom  Race-freedom is neither necessary nor sufficient to ensure the absence of errors due to unexpected interactions between threads  Is there a more fundamental semantic correctness property?

6 Sequential Program Execution void deposit() {.... } precond. postcond. deposit()

7 Multithreaded Program Execution void deposit() {.... }

8 Multithreaded Program Execution void deposit() {.... }

9 Multithreaded Program Execution  Atomicity –maximal non-interference property –enables sequential reasoning –matches existing methodology

10 Definition of Atomicity  deposit is atomic if for every non-serial execution, there is a serial execution with the same overall behavior (same final state)         acq(this)r=balbal=r+nrel(this)xyz         acq(this)r=balbal=r+nrel(this)xyz         acq(this)r=balbal=r+nrel(this)xyz  Serial execution of deposit  Non-serial executions of deposit public void deposit(int n) { synchronized(this) { int r = bal; bal = r + n; }

11 Atomizer: Dynamic Analysis  Lockset algorithm –from Eraser [Savage et al. 97] –identifies race conditions  Reduction [Lipton 75] –proof technique for verifying atomicity, using information about race conditions

12 Atomizer: Dynamic Analysis  Lockset algorithm –from Eraser [Savage et al. 97] –identifies race conditions  Reduction [Lipton 75] –proof technique for verifying atomicity, using information about race conditions

13 Atomizer: Dynamic Analysis  Lockset algorithm –from Eraser [Savage et al. 97] –identifies race conditions  Reduction [Lipton 75] –proof technique for verifying atomicity, using information about race conditions

14 Reduction [Lipton 75] acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0

15 Reduction [Lipton 75] X T 1 Y T 2 acq(this) T 3 j=bal S 4 bal=j+n S 5 rel(this) T 6 Z S 7 S0 S0 acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0

16 Commuting Actions 00 33 11 bc

17 Right Mover 00 33 22 00 33 11 bc cb b is right mover

18 Right Mover 00 33 22 00 33 11 ACQ(l,t)c c

19 Left Mover 00 33 22 00 33 11 bc cb c is left mover

20 Left Mover 00 33 22 00 33 11 bREL(l,t) b

21 Both Mover 00 33 22 00 33 11 bMEM(m,a,t) b m is always protected by the lockset L and at least one lock in L is held by t during the access

22 Non Mover 00 33 22 00 33 11 bMEM(m,a,t) b m is always protected by the lockset L and none of the locks in L is held by t during the access X

23  Reducible methods: (R|B)* [N] (L|B)* Performing Reduction Dynamically  R: right-mover –lock acquire  L: left-mover –lock release  B: both-mover –race-free field access  N: non-mover –access to "racy" fields InRightInLeft R|B L|N start atomic block Error L|B R|N acq(lock) j=bal bal=j+n rel(lock) R B B L

24 Reduction [Lipton 75] acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 green thread holds lock  red thread does not hold lock  operation y does not access balance (assuming balance protected by lock)  operations commute

25 Reduction [Lipton 75] acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 acq(this) S 1 X S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 green thread holds lock after acquire  operation x does not modify lock  operations commute

26 Reduction [Lipton 75] acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 acq(this) S 1 X S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 X T 1 acq(this) S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0

27 Reduction [Lipton 75] acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 acq(this) S 1 X S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 X T 1 acq(this) S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 X T 1 Y T 2 acq(this) T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0

28 Reduction [Lipton 75] X T 1 Y T 2 acq(this) T 3 j=bal S 4 bal=j+n S 5 rel(this) T 6 Z S 7 S0 S0 acq(this) S 1 X S 2 j=bal S 3 Y S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 acq(this) S 1 X S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 X T 1 acq(this) S 2 Y T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0 X T 1 Y T 2 acq(this) T 3 j=bal S 4 bal=j+n S 5 Z S 6 rel(this) S 7 S0 S0

29 class Account { private int balance = 0; atomic public read() { int r; synchronized(this) { r = balance; } return r; } Atomizer Goal atomic void deposit(int n) { synchronized(this) { int r = balance; balance = r + n; } Add two more event types: BEGIN and END

30 Atomizer Algorithm t.State = InRightt.State = InLeftWrong REL(l,t) MEM(m,a,t) and m is unprotected ACQ(l,t) t.State = OutsideAtomic REL(l,t) BEGIN END ACQ(l,t) MEM(m,a,t) and m is unprotected

31 Atomizer Review  Instrumented code calls Atomizer runtime –on field accesses, sync ops, etc  Lockset algorithm identifies races –used to classify ops as movers or non-movers  Atomizer checks reducibility of atomic blocks –warns about atomicity violations

32 Evaluation  12 benchmarks –scientific computing, web server, std libraries,... –200,000+ lines of code  Heuristics for atomicity –all synchronized blocks are atomic –all public methods are atomic, except main and run  Slowdown:1.5x - 40x

33 BenchmarkLines Base Time (s) Atomizer Slowdown elevator hedc29, tsp sor17, moldyn1, montecarlo3, raytracer1, mtrt11, jigsaw90, specJBB30, webl22, lib-java75,

34 Extensions  Redundant lock operations are both-movers –re-entrant acquire/release –operations on thread-local locks –operations on lock A, if lock B always acquired before A  Write-protected data

35 Write-Protected Data class Account { int bal; /*# atomic */ int read() { return bal; } /*# atomic */ void deposit(int n) { synchronized (this) { int j = bal; bal = j + n; } RBNLRBNL

36 Extensions Reduce Number of Warnings Total 341 Total 97

37 Evaluation  Warnings: 97 (down from 341)  Real errors (conservative): 7  False alarms due to: –simplistic heuristics for atomicity programmer should specify atomicity –false races –methods irreducible yet still "atomic" eg caching, lazy initialization  No warnings reported in more than 90% of exercised methods

38 java.lang.StringBuffer /**... used by the compiler to implement the binary string concatenation operator... String buffers are safe for use by multiple threads. The methods are synchronized so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved. */ /*# atomic */ public class StringBuffer {... }

39 public class StringBuffer { private int count; public synchronized int length() { return count; } public synchronized void getChars(...) {... } /*# atomic */ public synchronized void append(StringBuffer sb){ int len = sb.length();... sb.getChars(...,len,...);... } java.lang.StringBuffer sb.length() acquires lock on sb, gets length, and releases lock use of stale len may yield StringIndexOutOfBoundsException inside getChars(...) other threads can change sb

40 public class StringBuffer { private int count; public synchronized int length() { return count; } public synchronized void getChars(...) {... } /*# atomic */ public synchronized void append(StringBuffer sb){ int len = sb.length();... sb.getChars(...,len,...);... } java.lang.StringBuffer StringBuffer.append is not atomic: Start: at StringBuffer.append(StringBuffer.java:701) at Thread1.run(Example.java:17) Commit: Lock Release at StringBuffer.length(StringBuffer.java:221) at StringBuffer.append(StringBuffer.java:702) at Thread1.run(Example.java:17) Error: Lock Acquire at StringBuffer.getChars(StringBuffer.java:245) at StringBuffer.append(StringBuffer.java:710) at Thread1.run(Example.java:17)

41 Related Work  Reduction –[Lipton 75, Lamport-Schneider 89,...] –type systems [Flanagan-Qadeer 03], model checking [Stoller-Cohen 03, Flanagan-Qadeer 03], procedure summaries [Qadeer et al 04]  Other atomicity checkers –[Wang-Stoller 03], Bogor model checker [Hatcliff et al 03]  Race detection / prevention –dynamic [Savage et al 97, O'Callahan-Choi 01, von Praun-Gross 01] –Warlock [Sterling 93], SPMD [Aiken-Gay 98] –type systems [Abadi-Flanagan 99, Flanagan-Freund 00, Boyapati-Rinard 01] –Guava [Bacon et al 01]  View consistency [Artho-Biere-Havelund 03, von Praun-Gross 03]

42 atomic Multithreaded Program Execution run() b() d() a()

43 Multithreaded Program Execution run() b() d() a() atomic

44 Conclusions And Future Directions  Atomicity –maximal non-interference property –enables sequential reasoning –matches practice  Atomizer extends race detection techniques –catches "higher-level" concurrency errors –some benign races do not break atomicity  Atomicity for distributed systems?