Magiclock: Scalable Detection of Potential Deadlocks in Large-Scale Multithreaded Programs

Cai, Yan; Chan, W. K.

doi:10.1109/tse.2014.2301725

Cited by 45 publications

(19 citation statements)

References 34 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similar to iGoodLock, MulticoreSDK addresses prediction of deadlocks by searching over the lock‐order graph. In comparison with iGoodLock and MulticoreSDK, MagicLock improved the search on the lock‐order graph using a forecast mechanism.…”

Section: Related Workmentioning

confidence: 99%

Runtime deadlock tracking and prevention of concurrent multithreaded programs: A learning‐based approach

Ghorbani

Babamir

2019

Concurrency and Computation

View full text Add to dashboard Cite

Allocation of shared resources by multithreaded programs faces problem of deadlock. Many solutions have been presented to resolve this problem. Among others, the deadlock prevention is stressed when the deadlock detection and removal are costly. Removing deadlocks, which is carried out by aborting/recovering deadlocked threads, causes the waste of the resources used by the deadlocked threads. In such case, deadlock prevention can lead to avoiding the waste of resources. To this end, the runtime behavior of threads should be monitored in order to predict possible future deadlocks. In such case, the prediction mechanism becomes significant because a proper prediction helps us deny the allocation request of a resource by a thread if the allocation leads to a potential deadlock. A method to attain to proper prediction is learning the behavior of threads based on runtime monitoring their past behavior. In fact, based on past behavior of threads, potential deadlocks in their future behavior are verified, and current allocation request of a resource is denied if a future deadlock is predicted. The current study is an extension of our previous work where just deadlock tracking was predicted and no adaptation was suggested. In this study, a composite structure of a recurrent Neural Network (NN) called NARX (to track a potential deadlock) and a Multi-perceptron NN called MLP (to select a suitable action to resolve the potential deadlock) is proposed. Based on the experimental results, the accuracy of the first NN was about 80%, leading to high performance of the second NN, and more than 82% of the real deadlocks were prevented by selecting suitable actions.

show abstract

Section: Related Workmentioning

confidence: 99%

Runtime deadlock tracking and prevention of concurrent multithreaded programs: A learning‐based approach

Ghorbani

Babamir

2019

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…DeadlockFuzzer [21] use a fuzzying technique to search for deadlocking executions. Multicore SDK [27] tries to reduce the size of lock graphs by clustering locks; and Magiclock [10] implements significant improvements on the cycle detection algorithms. Helgrind [1] is a popular open source dynamic deadlock detection tool, and there are many commercial implementations of dynamic deadlock detection algorithms.…”

Section: Dynamic Toolsmentioning

confidence: 99%

Sound static deadlock analysis for C/Pthreads

Kroening

Poetzl

Schrammel

et al. 2016

Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

We present a static deadlock analysis approach for C/pthreads. The design of our method has been guided by the requirement to analyse real-world code. Our approach is sound (i.e., misses no deadlocks) for programs that have defined behaviour according to the C standard, and precise enough to prove deadlock-freedom for a large number of programs. The method consists of a pipeline of several analyses that build on a new context-and thread-sensitive abstract interpretation framework. We further present a lightweight dependency analysis to identify statements relevant to deadlock analysis and thus speed up the overall analysis. In our experimental evaluation, we succeeded to prove deadlockfreedom for 262 programs from the Debian GNU/Linux distribution with in total 2.6 MLOC in less than 11 hours. CCS Concepts•Theory of computation → Program analysis; Keywords deadlock detection, lock analysis, static analysis, abstract interpretation 1 i n t main ( ) 2 { 3 p t h r e a d _ t t i d ; 4 5 p t h r e a d _ c r e a t e (& t i d , 0 , 6 thread , 0 ) ; 7 8 pthread_mutex_lock (&m1 ) ; 9 pthread_mutex_lock (&m3 ) ; 10 pthread_mutex_lock (&m2 ) ; 11 func1 ( ) ; 12 pthread_mutex_unlock(&m2 ) ; 13 pthread_mutex_unlock(&m3 ) ; 14 pthread_mutex_unlock(&m1 ) ; 15 16 p t h r e a d _ j o i n ( t i d , 0 ) ; 17 18 i n t r ; 19 r = func2 ( 5 ) 20 21

show abstract

“… others (e.g., memory read and write) An execution trace (or a trace) is a sequence of events. A deadlock occurs if a set of threads wait mutually for a set of locks that are held by other threads in the same set [15] [32]. For example, Figure 1 shows an example program with a deadlock D1.…”

Section: Preliminaries and Motivations 21 Events And Deadlocksmentioning

confidence: 99%

“…A deadlock occurs when a set of threads are holding some locks and are waiting for other locks held by the threads in the same set [8][31] [32]. There are both static [45][56] [61] and dynamic approaches [8] [11] [15][31] [46][53] to detect deadlocks. However, static approaches may report false positives as it is difficult to infer whether two events may occur concurrently [31].…”

Section: Introductionmentioning

confidence: 99%

Radius aware probabilistic testing of deadlocks with guarantees

Cait

Yang

2016

Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering

Self Cite

View full text Add to dashboard Cite

Concurrency bugs only occur under certain interleaving. Existing randomized techniques are usually ineffective. PCT innovatively generates scheduling, before executing a program, based on priorities and priority change points. Hence, it provides a probabilistic guarantee to trigger concurrency bugs. PCT randomly selects priority change points among all events, which might be effective for non-deadlock concurrency bugs. However, deadlocks usually involve two or more threads and locks, and require more ordering constraints to be triggered. We interestingly observe that, every two events of a deadlock usually occur within a short range. We generally formulate this range as the bug Radius, to denote the max distance of every two events of a concurrency bug. Based on the bug radius, we propose RPro (Radius aware Probabilistic testing) for triggering deadlocks. Unlike PCT, RPro selects priority change points within the radius of the targeted deadlocks but not among all events. Hence, it guarantees larger probabilities to trigger deadlocks. We have implemented RPro and PCT and evaluated them on a set of real-world benchmarks containing 10 unique deadlocks. The experimental results show that RPro triggered all deadlocks with higher probabilities (i.e., >7.7x times larger on average) than that by PCT. We also evaluated RPro with radius varying from 1 to 150 (or 300). The result shows that the radius of a deadlock is much smaller (i.e., from 2 to 114 in our experiment) than the number of all events. This further confirms our observation and makes RPro meaningful in practice. CCS Concepts• Software and its engineering➝Deadlocks • Software and its engineering➝Software testing and debugging.

show abstract

Magiclock: Scalable Detection of Potential Deadlocks in Large-Scale Multithreaded Programs

Cited by 45 publications

References 34 publications

Runtime deadlock tracking and prevention of concurrent multithreaded programs: A learning‐based approach

Runtime deadlock tracking and prevention of concurrent multithreaded programs: A learning‐based approach

Sound static deadlock analysis for C/Pthreads

Radius aware probabilistic testing of deadlocks with guarantees

Contact Info

Product

Resources

About