Eraser: A dynamic Data Race Detector for Multithreaded Programs Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, Thomas Anderson Presenter: Chao Kong EECS 582 – W161

Outline Introduction Previous works The Lockset Algorithm Eraser implementation Case Studies EECS 582 – W162

Introduction Multithreading is prevalent. Microsoft Word and Netscape Navigator Multithreaded programs easily produce timing-dependent data races caused by simple synchronization errors. EECS 582 – W163

Data Race A data race occurs when multiple concurrent threads access a shared variable : At least one access is a write No explicit mechanism to prevent simultaneous accesses EECS 582 – W164 Thread 1 Thread 2

Previous works Monitors: Avoid data races of shared variables which are static globals Sun’s lock_lint and Extended Static Checker for Modula-3 Work in dynamically allocated shared data Problematical: requires statically reasoning about the program’s semantics Happens-before EECS 582 – W165

Happens-before Happens-before relation Within single thread Between threads Accessing variables not ordered by happens-before relation leads to potential data race EECS 582 – W166 Thread 1 Thread 2

y := y+1; Lock(mu); v := v+1; Unlock(mu); Flaws of Happens-before Difficult to implement Requires per-thread information Dependent on the interleaving produced by the scheduler EECS 582 – W167 Lock(mu); v := v+1; Unlock(mu); y := y+1; Thread 1 Thread 2

y := y+1; Lock(mu); v := v+1; Unlock(mu); Flaws of Happens-before Difficult to implement Requires per-thread information Dependent on the interleaving produced by the scheduler EECS 582 – W168 Thread 1 Lock(mu); v := v+1; Unlock(mu); y := y+1; Thread 2

Lockset Algorithm Locking discipline Every shared variable is protected by some locks Infer protection relation Infer which locks protect which variable from execution history. EECS 582 – W169

Lockset Algorithm Example EECS 582 – W1610

Limitations Initialization shared variables are frequently initialized without holding a lock Read-shared Data Some shared variables are written during initialization only and are read-only thereafter Read-Write Locks Read-write locks allow multiple readers to access a shared variable, but allow only a single writer to do so. EECS 582 – W1611

Read-Write Locks EECS 582 – W1612 Lock(mu1); v := v+1; Lock(mu2); w=v; Unlock(mu2); Unlock(mu1); Lock(mu2); w := v; Unlock(mu2); Locks-held C(v) {mu1,mu2} {} {mu1,mu2} {mu2} {}

Refinement-I Initialization  Don’t start until see a second thread Read-shared Data  Report only after it becomes write shared EECS 582 – W1613

Refinement-II EECS 582 – W1614 Reader-writer locking  Change algorithm to reflect lock type Page 22

Read-Write Locks EECS 582 – W1615 Lock(mu1); v := v+1; Lock(mu2); w=v; Unlock(mu2); Unlock(mu1); Lock(mu2); w := v; Unlock(mu2); Locks-held C(v) {mu1,mu2} {} {mu1} {mu2} {}

Implementation Binary rewriting used  Add instrumentation to call Eraser runtime  Calls to storage allocator initializes C(v)  Each Acquire and Release call updates locks-held(t)  Each load and store updates C(v) Storage explosion handled by table lookup and use of indexes to represent set  Shadow word holds index number EECS 582 – W1616

Shadow Memory and Lockset Indexes EECS 582 – W1617

Performance Slowdown by factor of 10 to 30x overhead of making a procedure call at every load and store instruction change thread order affect the behavior of time-sensitive applications EECS 582 – W1618

Common false alarms - Annotations Memory reuse Private locks Benign race EECS 582 – W1619  EraserReuse(address,size) Resets shadow word to virgin state  Lock annotations EraserReadLock/Unlock(lock) EraserWriteLock/Unlock(lock)  EraserlgnoreOn() EraserlgnoreOff()

Races inside OS Using interrupt system to provide mutual exclusion – this implicitly locks everything affected (by interrupt level specified) Explicitly associate a lock with interrupt level – disabling interrupt is like acquiring that lock Signal and wait kind of synchronization V to signal for P which waits -- semaphore not “held” by thread. EECS 582 – W1620

A Race for optimization in AltaVista EECS 582 – W1621

Data Race in Vesta EECS 582 – W1622

Conclusion The paper describes a new tool, called Eraser, for dynamically detecting data races in lock-based multithreaded programs. The paper evaluates the performance and overhead of Eraser The paper tells the experience of detecting data race by several case studies. EECS 582 – W1623

Questions Thank you !!! EECS 582 – W1624