Deadlocks: From Exhibiting to Healing

Nir-Buchbinder, Yarden; Tzoref, Rachel; Ur, Shmuel

doi:10.1007/978-3-540-89247-2_7

Cited by 39 publications

(27 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Deadlock immunity approaches include [5,9]. These approaches dynamically detect deadlocks, then avoid future occurrences of the same deadlocks.…”

Section: Related Workmentioning

confidence: 99%

“…If a deadlock involving threads t 1 and t 2 and locks l 1 and l 2 occurs, the two approaches save the program positions p 1 and p 2 (where l 1 and l 2 were acquired) into the signature of the deadlock; [9] saves, in addition, the positions p ′ 1 and p ′ 2 where t 1 and t 2 deadlocked. In future runs, [5,9] prevent the deadlock from reoccurring by acquiring a "gate lock" every time the lock statement at p 1 or p 2 is about to execute. If the lock at p ′ 1 (or p ′ 2 ) can be soundly inferred at runtime from p 1 (respectively p 2 ), [9] swaps the lock acquisitions at p 1 and p ′ 1 (respectively p 2 and p ′ 2 ), instead of acquiring a gate lock.…”

Section: Related Workmentioning

confidence: 99%

“…Dimmunix shares ideas with [5,9], but uses a more accurate avoidance mechanism. Like in these approaches, Dimmunix's deadlock avoidance mechanism relies on temporarily suspending threads.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Efficiency Optimizations for Implementations of Deadlock Immunity

Jula

Andrica

Candea

2012

Runtime Verification

View full text Add to dashboard Cite

Abstract. Deadlock immunity is a property by which programs, once afflicted by a deadlock, develop resistance against future occurrences of that deadlock. Our deadlock immunity system, called Dimmunix, provides transparent immunization against deadlocks involving mutex locks. In this paper, we focus on efficiently protecting systems against deadlocks regardless of the rate of synchronization operations performed. We describe five optimizations that reduce the runtime overhead imposed by Dimmunix on the host system: (1) offline deadlock detection and signature extraction, which avoids runtime tracking of lock-to-thread allocations; (2) selective program instrumentation, whereby only vulnerable synchronization statements are monitored; (3) inline matching of deadlock signatures, which avoids expensive call stack retrieval; (4) false positive reduction, which avoids unnecessary thread serialization; and (5) safe early resumption of threads, allowing suspended threads to resume their execution more quickly than in the original Dimmunix. Our optimizations enable Dimmunix to achieve a reduction of 2.8x-5.2x in the runtime overhead it introduces for real-world systems like Eclipse, Vuze, and MySQL JDBC.

show abstract

“…Deadlock immunity approaches include [5,9]. These approaches dynamically detect deadlocks, then avoid future occurrences of the same deadlocks.…”

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Efficiency Optimizations for Implementations of Deadlock Immunity

Jula

Andrica

Candea

2012

Runtime Verification

View full text Add to dashboard Cite

show abstract

“…There are tools that provide immunity against failures like deadlocks [1], [2], data races and atomicity violations [3], [4], [5], and buffer overruns [6]; however, to the best of our knowledge, Android Dimmunix is (1) the first system that provides platform-wide failure immunity, and (2) the first system providing failure immunity to mobile phone applications.…”

Section: Introductionmentioning

confidence: 99%

Platform-wide deadlock immunity for mobile phones

Jula

Rensch

Candea

2011

2011 IEEE/IFIP 41st International Conference on Dependable Systems and Networks Workshops (DSN-W)

View full text Add to dashboard Cite

Abstract-We present an implementation of our deadlock immunity system, Dimmunix, for mobile phone software. Within Android 2.2 OS, we modified Dalvik VM, the JVM running all the Android applications, to provide platform-wide deadlock immunity. We successfully ran the Dimmunix-enabled Android 2.2 OS on a Nexus One phone. On the phone, we reproduced a real deadlock involving Android's NotificationManagerService and StatusBarService classes, which froze the entire phone's interface. Android Dimmunix successfully detected the deadlock, and subsequently prevented its reoccurrence, with no user intervention. Our tests show that Android Dimmunix incurs 4-5% performance overhead and 4% memory overhead. Therefore, Android Dimmunix is a practical and efficient solution to cope with deadlocks on mobile phones. To the best of our knowledge, Android Dimmunix is the first failure immunity system for mobile phones, and the first one to provide platformwide failure immunity.

show abstract

“…The method in [7] generates a scheduler (from deadlock potentials) that attempts to drive the application into a deadlock. Finally, the work in [8] involves the informing of a scheduling Bnoise maker[ of deadlock potentials. The noise maker inserts code that influences the scheduler, avoiding the need for a special scheduler.…”

Section: Introductionmentioning

confidence: 99%

Detection of deadlock potentials in multithreaded programs

et al. 2010

View full text Add to dashboard Cite

Concurrent programs are well known for containing errors that are difficult to detect, reproduce, and diagnose. Deadlock is a common concurrency error, which occurs when a set of threads are blocked, due to each attempting to acquire a lock held by another. This paper presents a collection of highly scalable static and dynamic techniques for exposing potential deadlocks. The basis is a known algorithm, which, when locks are acquired in a nested fashion, captures the nesting order in a lock graph. A cycle in the graph indicates a deadlock potential. We propose three extensions to this basic algorithm to eliminate, or label as low severity, false warnings of possible deadlocks (false positives). These false positives may be due to cycles within one thread, cycles guarded by a gate lock (an enclosing lock that prevents deadlocks), and cycles involving several code fragments that cannot possibly execute in parallel. We also present a technique that combines information from multiple runs of the program into a single lock graph, to find deadlock potentials that would not be revealed by analyzing one run at a time. Finally, this paper describes the use of static analysis to automatically reduce the overhead of dynamic checking for deadlock potentials. IntroductionConcurrent programs are well known for containing errors that are difficult to detect, reproduce, and diagnose. Some common programming errors include data races and deadlocks. A data race occurs when two or more threads concurrently access a shared variable, at least one of the accesses is a write, and no mechanism is used to enforce mutual exclusion. Data races can be avoided by proper use of locks. However, the use of locks introduces the potential for deadlocks. Two types of deadlocks, namely, resource deadlocks and communication deadlocks, are discussed in the literature [1,2]. In the case of resource deadlocks, a set of threads are deadlocked if each thread in the set is waiting to acquire a lock held by another thread in the set. In the case of communication deadlocks, threads wait for messages or signals that do not occur. In the Java** programming language, resource deadlocks result from the use of synchronized methods and synchronized statements.Communication deadlocks result from the use of the wait and notify primitives. The algorithms presented in this paper address resource deadlocks, from now on referred to as deadlocks, illustrated by example programs written in Java.Deadlocks can be analyzed using a variety of techniques, such as model checking (using algorithms that explore all possible behaviors of a program), dynamic analysis (analyzing only one or just a few executions), and static analysis (analyzing the source code without executing it). Model checking is computationally expensive and often impractical for large software applications. Static analysis can guarantee that all executions of a program are deadlock free but often yields false warnings of possible deadlocks, also called false positives or false alarms. Dynamic analysis general...

show abstract

Deadlocks: From Exhibiting to Healing

Cited by 39 publications

References 13 publications

Efficiency Optimizations for Implementations of Deadlock Immunity

Efficiency Optimizations for Implementations of Deadlock Immunity

Platform-wide deadlock immunity for mobile phones

Detection of deadlock potentials in multithreaded programs

Contact Info

Product

Resources

About