1 / 22

A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks

This paper presents a randomized dynamic program analysis technique for detecting real deadlocks in multi-threaded programs. The algorithm aims to report only real deadlocks while minimizing false positives and negatives. The technique uses lock dependency relations and thread scheduling to identify potential deadlocks and schedule threads to ensure a deadlock occurs. The implementation and results show that the technique performs well at detecting known deadlocks and finding new ones.

settle
Download Presentation

A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks Pallavi Joshi, Chang-Seo Park, KoushikSen and MayurNaik* (UC Berkeley & *ILB) PLDI 2009 Slides by Michelle Goodstein 10/5/10

  2. Motivation • Deadlocks difficult to find in testing • Only occur under specific interleavings • Static tools can suffer from high false positives (7/100,000 real) • Annotations incur high overhead • Predictive tools have both false positives and false negatives • “Predictive”: using data from an instrumented execution to predict later executions • Goal: Algorithm that only reports real deadlocks

  3. Outline • Motivation • Algorithm/Definitions • Potential Deadlock Detection • Checking Potential Deadlocks • Implementation/Results • Conclusions

  4. DeadlockFuzzer • Idea: • Take deadlock detector (like Goodlock) that suffers from both false positives/negatives • For all reported deadlocks, try to schedule threads to ensure deadlock occurs

  5. Part 1: Compute Potential Deadlocks • Given an execution, a lock dependency relation D is such that tuple (t, L, l, C)  D iff at some state in the execution, thread t acquires lock l while holding locks in L in context C • t: thread id, C: seq of labels of Acquire() stmts • l: lock about to acquire, L: set of locks held

  6. Part 1, continued • Dependency chain: <(t1,L1,l1,C1),…,(tm,Lm,lm,Cm)> is a sequence such that: • For all i  j, ti tj (distinct threads) • For all i  j, li lj (locks to acquire are distinct) • For all i [1,m-1], li Lm+1 (each thread could wait for lock held by next thread) • For all i,j [1, m], i  j, LiLj = (each thread can acquire lockset Lj without waiting

  7. Part 1, continued • Lock dependency chains lead to potential deadlock cycles if lm L1 • Purpose of context (C in relation): use to compute unique ID of object • After it is “abstracted”….

  8. Calculating Dk (k-length) • Init: D1 = D (where D is lock dependency relation for entire execution)

  9. Challenge: Abstractions • During phase 1: Unique ID of object often address • Address changes between iterations! • Need an abstraction, id based only on static info • Two abstraction techniques: • K-object sensitivity (skipping) • Light-weight execution indexing (next example)

  10. absk(o): sequence of (…ci,qi,…) s.t. c1 is label of statement that creates o and q1 is # of times statement is executed in call stack (k-deep) Example (k=3, call depth) First object: [11,1,6,1,3,1] Last object:[11,3,7,1,3,5] Light-weight execution indexing 5 1 1 1 1 3

  11. Phase 2: Checking for Real Deadlocks • Idea: schedule threads randomly • But want high probability of achieving deadlock! • When thread t is about to acquire lock l in context C and (t,l,C) is part of the cycle we’re testing: • Delay acquiring locks • Gives chance for another thread in potential deadlock cycle to acquire lock first • Biases probability of observing deadlock

  12. Abstraction: t1 o2 t2 o1 context context Example

  13. Implementation • Instrumenting Java bytecode • Dual socket Intel Xeon 2Ghz quad-server with 8GB RAM • Multiple benchmarks • Includes: Jigsaw, web server platform from W3C

  14. Results

  15. Performance/Probability

  16. Finding new deadlocks Shutdown (orange): lock factory, try to lock csList SocketClient closing (lavender): lock csList, try to lock factory

  17. Addressing Imprecision • iGoodlock is incomplete • Cannot tell whether predicted-but-not-produced deadlocks are false positives • Sometimes, happens-before info from lock acquire/release would help (18 cases in Jigsaw) • All others—could not manually decide

  18. Conclusion • Deadlock detector that can point out real deadlocks • Interesting combination of deadlock prediction algorithm with thread scheduler • While imprecise, still does well at detecting known deadlocks and finding new ones

  19. Extra

  20. Calculating relation

More Related