1. 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

2. 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

3. 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

4. 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; } … }

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

6. 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

7. 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

8. 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

9. 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

10. 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) }

11. University of Michigan Electrical Engineering and Computer Science Lock/Unlock Pairing Example 11 2. 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: }

12. 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

13. 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: }

14. University of Michigan Electrical Engineering and Computer Science CFG Pruning 14 1 2 4 3 56 7 89 10 11 1 3,5,6 7 9 2,4,8,10,11

15. 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

16. 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

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

18. University of Michigan Electrical Engineering and Computer Science Effectiveness of Static Analysis 18 BenchmarksLOCLocksTrivialDFT Our Approach Statically Paired Speculatively Paired Total Paired Unpaired OpenLDAP271K357110267319343534 MySQL926K4991474284632648910 Apache224K1900170 2 pbzip240113012130 pfscan75211810 1110 aget8352222020

19. University of Michigan Electrical Engineering and Computer Science Runtime Overhead 19

20. 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