University of Michigan Electrical Engineering and Computer Science 1 Practical Lock/Unlock Pairing for Concurrent Programs Hyoun Kyu Cho 1, Yin Wang 2, Hongwei Liao 1, Terence Kelly 2, Stéphane Lafortune 1, Scott Mahlke 1 1 University of Michigan 2 Hewlett-Packard Labs

University of Michigan Electrical Engineering and Computer Science Parallel Programming Industry wide move to multicores forces parallel programming Inherently difficult –Concurrency bugs –Non-determinism 2 Intel 4 Core Nehalem AMD 4 Core ShanghaiSun Niagara 2IBM Cell

University of Michigan Electrical Engineering and Computer Science Tools for Parallel Programs 3 Concurrency bug detection tools –To statically infer concurrency –ex) RacerX[Engler`03] Automated bug fix tools –To avoid deadlocks –ex) AFix[Jin`11], Gadara[Wang`08] Optimizing compilers –Accurate synchronization information can enable more aggressive optimizations

University of Michigan Electrical Engineering and Computer Science Examples 4 13: Node* iterate_next(Node *current) 14: { 15: Node *next = find(current); 16: … 17: lock(next->mutex); 18: unlock(current->mutex); 19: … 20: return next; 21: } 1 : int work_on_tree(…) 2 : { 3 : Node *ptr1, *ptr2; 4 : … 5 : lock( ptr->mutex ); 6 : while( ptr != NULL ) { 7 : … 8 : ptr2 = iterate_next( ptr1 ); 9 : ptr1 = ptr1; 10: } 11: unlock( ptr->mutex ); 12: } public class Counter { … public void increment() { synchronized (this) { ++count; } … }

University of Michigan Electrical Engineering and Computer Science Unpaired Locks and Unlocks 5 Challenges –Infeasible paths

University of Michigan Electrical Engineering and Computer Science Unpaired Locks Due To Infeasible Paths 6 Example void foo(x, A) { if (x) lock(A); … if (x) unlock(A); } lock(A); … if(x) unlock(A); true false FeasibleInfeasible

University of Michigan Electrical Engineering and Computer Science Unpaired Locks and Unlocks 7 Challenges –Infeasible paths –Spanning function boundaries –Pointers Impacts –False positives –Need programmers’ annotation –Conservative, less efficient

University of Michigan Electrical Engineering and Computer Science Practical Lock/Unlock Pairing 8 For a lock, give a set of pairing unlocks and check if the mutex would be released by them for all feasible paths Path-sensitive analysis using a SAT solver Use heuristics based on likely assumptions Instrument code for dynamic checking

University of Michigan Electrical Engineering and Computer Science Static Analysis 9 Mapping Lock to Set of Corresponding Unlocks Path Condition Calculation Checking Lock/Unlock Pairing

University of Michigan Electrical Engineering and Computer Science Lock/Unlock Pairing Example 10 01: int foo(struct Task *job) { 02: … 03: if(job->hasMutex) 04: lock(job->mutex); //(1) 05: if(job->isSpecial) { 06: // Do some special work 07: if(job->hasMutex) 08: unlock(job->mutex); //(2) 09: return result; 10: } 11: // Do normal work 12: if(job->hasMutex) 13: unlock(job->mutex); //(3) 14: return result; 15: } 1. Map set of corresponding unlocks (1) → { (2), (3) }

University of Michigan Electrical Engineering and Computer Science Lock/Unlock Pairing Example Calculate Boolean expressions (1): (2): (3): (1): (2): (3): 01: int foo(struct Task *job) { 02: … 03: if(job->hasMutex) 04: lock(job->mutex); //(1) 05: if(job->isSpecial) { 06: // Do some special work 07: if(job->hasMutex) 08: unlock(job->mutex); //(2) 09: return result; 10: } 11: // Do normal work 12: if(job->hasMutex) 13: unlock(job->mutex); //(3) 14: return result; 15: }

University of Michigan Electrical Engineering and Computer Science Path Condition Calculation 12 Recursively calculate path conditions that decide execution of each lock and unlock Join Point  Disjunction (OR) Consecutive conditions in a path  Conjunction (AND) src child1child2 dest x=truex=false Assign same Boolean variable to Branch conditions that should have same value

University of Michigan Electrical Engineering and Computer Science Lock/Unlock Pairing Example 13 3.Examine pairing (1) is paired up with { (2), (3) }. If (1) is executed, (2) or (3) is executed. 01: int foo(struct Task *job) { 02: … 03: if(job->hasMutex) 04: lock(job->mutex); //(1) 05: if(job->isSpecial) { 06: // Do some special work 07: if(job->hasMutex) 08: unlock(job->mutex); //(2) 09: return result; 10: } 11: // Do normal work 12: if(job->hasMutex) 13: unlock(job->mutex); //(3) 14: return result; 15: }

University of Michigan Electrical Engineering and Computer Science CFG Pruning ,5, ,4,8,10,11

University of Michigan Electrical Engineering and Computer Science Inter-procedural Analysis Observations –Corresponding unlocks share lowest common ancestor (LCA) in the callgraph –Depths from locks and unlocks to LCA relatively small Proximity-based Callgraph Partitioning Extend pairing analysis with context 15

University of Michigan Electrical Engineering and Computer Science Dynamic Checking Checking Lock-to-Unlocks Mapping –Keeps a map structure from mutex to acquired LOCK_ID –When released, check if UNLOCK_ID is in corresponding unlock set of LOCK_ID Checking Semiflow Property –Keeps a map structure from function to mutex –When function returns, check if holding a mutex that should not be held 16

University of Michigan Electrical Engineering and Computer Science Experimental Setup 17 Implemented pairing in LLVM compiler infrastructure Benchmarks –Apache web server –MySQL database server –OpenLDAP lightweight directory access protocol server –pbzip –pfscan 1.0 –aget 0.4 On an Intel Core 2 Quad w/ 8GB MEM

University of Michigan Electrical Engineering and Computer Science Effectiveness of Static Analysis 18 BenchmarksLOCLocksTrivialDFT Our Approach Statically Paired Speculatively Paired Total Paired Unpaired OpenLDAP271K MySQL926K Apache224K pbzip pfscan aget

University of Michigan Electrical Engineering and Computer Science Runtime Overhead 19

University of Michigan Electrical Engineering and Computer Science Conclusion 20 Practical Lock/Unlock Pairing –Combines static analysis and dynamic checking –Infeasible path analysis using path conditions –Makes likely assumptions and check at runtime Overall, pairs up 98.2% of all locks including 7.1% of them paired speculatively Negligible runtime overhead of 3.4% at most