Eraser A dynamic Data Race Detector for Multithreaded

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

Outline • Introduction • Previous works • The Lockset Algorithm • Eraser implementation • Case Studies EECS 582 – W 16 2

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

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

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 – W 16 5

Thread 1 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 – W 16 Thread 2 6

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

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

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 – W 16 9

Lockset Algorithm Example EECS 582 – W 16 10

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 – W 16 11

Read-Write Locks Lock(mu 1); v : = v+1; Locks-held {} C(v) {mu 1, mu 2} Lock(mu 2); {mu 1, mu 2} w=v; Unlock(mu 2); Unlock(mu 1); Lock(mu 2); {} {mu 2} w : = v; {mu 2} Unlock(mu 2); EECS 582 – W 16 12

Refinement-I • Initialization ØDon’t start until see a second thread • Read-shared Data ØReport only after it becomes write shared EECS 582 – W 16 13

Refinement-II • Reader-writer locking ØChange algorithm to reflect lock type Page 22 EECS 582 – W 16 14

Read-Write Locks Lock(mu 1); v : = v+1; Locks-held {} C(v) {mu 1, mu 2} {mu 1} Lock(mu 2); {mu 1} w=v; Unlock(mu 2); Unlock(mu 1); Lock(mu 2); {} {mu 2} w : = v; {} Unlock(mu 2); EECS 582 – W 16 15

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 – W 16 16

Shadow Memory and Lockset Indexes EECS 582 – W 16 17

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

Common false alarms - Annotations • Memory reuse Ø Eraser. Reuse(address, size) • • Private locks • Benign race Resets shadow word to virgin state Ø Lock annotations • • Eraser. Read. Lock/Unlock(lock) Eraser. Write. Lock/Unlock(lock) Ø Eraserlgnore. On() Eraserlgnore. Off() EECS 582 – W 16 19

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 – W 16 20

A Race for optimization in Alta. Vista EECS 582 – W 16 21

Data Race in Vesta EECS 582 – W 16 22

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 – W 16 23

Questions • Thank you !!! EECS 582 – W 16 24