Yarden Nir-Buchbinder

Deadlocks: From Exhibiting to Healing

Deadlocks are possibly the best known bug pattern in computer systems in general; certainly they are the best known in concurrent programming. Numerous articles, some dating back more than 40 years, have been dedicated to the questions of how to design deadlock free programs, how to statically or dynamically detect possible deadlocks, how to avoid deadlocks at runtime, and how to resolve deadlocks once they happen. We start the paper with an investigation on how to exhibit potential deadlocks. Exhibiting deadlocks is very useful in testing, as verifying if a potential deadlock can actually happen is a time-consuming debugging activity. There was recently some very interesting research in this direction; however, we believe our approach is more practical, has no scaling issues, and in fact is already industry-ready. The second contribution of our paper is in the area of healing multi-threaded programs so they do not get into deadlocks. This is an entirely new approach, which is very different from the approaches in the literature that were meant for multi-process scenarios and are not suitable (and indeed not used) in multithreaded programming. While the basic ideas are fairly simple, the details here are very important as any mistake is liable to actually create new deadlocks. The paper describes the basic healing idea and its limitations, the pitfalls and how to overcome them, and experimental results.

Detection of deadlock potentials in multithreaded programs

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.

Forcing small models of conditions on program interleaving for detection of concurrent bugs

Is it possible to efficiently reveal concurrency bugs by forcing a well selected set of conditions on program interleaving? To study this general question, we defined two simple models of conditions on program interleaving targeted at the insufficient-synchronization-scope bug pattern. We analyzed these models with respect to several buggy programs. We also implemented an algorithm that tries to force one of these models. The analysis of these models shows that relatively small models can detect insufficient-synchronization-scope bugs. The experiments with the forcing algorithm demonstrated the ability of finding the bug with high efficiency: the average testing time till the bug is detected was improved by factors of 7 and 73 compared with the average time required by a dynamic exploration that did not incorporate the forcing algorithm.

ConTest listeners: a concurrency-oriented infrastructure for Java test and heal tools

With the proliferation of the new multi-core personal computers, and the explosion of the usage of highly concurrent machine configuration, concurrent code moves from being written by the select few to the masses. As anyone who has written such code knows, there are many traps awaiting. This increases the need for good concurrency-aware tools to be used in the program quality cycle: monitoring, testing, debugging, and the emerging field of self-healing. Academics who build such tools face two main difficulties; writing the instrumentation infrastructure for the tool, and integrating it into real user environments to obtain meaningful results. As these difficulties are hard to overcome, most academic tools do not make it past the toy stage. The ConTest Listener architecture provides instrumentation and runtime engines to which writers of test and heal tools, especially concurrency-oriented, can easily plug their code. This paper describes this architecture, mainly from the point of view of a user intending to create a testing/healing tool. This architecture enables tool creators to focus on the concurrent problem they are trying to solve without writing the entire infrastructure. In addition, once they create a tool within the ConTest Listeners framework the tool can be used by the framework users with no additional work, enabling access to real industrial applications. We show how to create tools using the architecture and describe some work that has already taken place.

Future Internet Testing with FITTEST

The complexity of the technologies involved in the Future Internet makes testing extremely challenging and demands for novel approaches and major advancement in the field. The overall aim of the FITTEST project is to address these testing challenges, by developing an integrated environment for automated testing, which can monitor the Future Internet application under test and adapt to the dynamic changes observed. Future Internet applications do not remain fixed after their release, services and components can be dynamically added by customers. Consequently, FITTEST testing will be continuous and post-release such that maintenance and quality assurance can cope with the changes in the intended use of an application after release. The testing environment will integrate, adapt and automate various techniques for continuous Future Internet testing (dynamic model inference, model-based testing, log-based diagnosis, oracle learning, combinatorial testing, concurrent testing, regression testing).