Concurrency bugs are notoriously hard to identify and fix. A systematic way of avoiding concurrency bugs is to design and implement a locking policy that consistently guards all shared variables. Concurrency bugs thus can be viewed as the result of an illy-designed or poorly implemented locking policy. The trouble is that the locking policy is often not documented, which makes debugging concurrency bugs clueless. We argue that it is too late to debug concurrency bugs after programming is done and we instead detect and fix them while they are being implemented. In this work, we propose an approach named IFIX which flags potential concurrency bugs and recommends fixes while the bugs are introduced. The key idea is to automatically conjecture what the intended locking policy is based on static analysis and recommend fixes accordingly. The recommended fixes are present to the programmer promptly and the user feedback (i.e., whether the certain recommendation is selected) is used to refine the conjectured locking policy and consequently future fixes. IFIX is evaluated on 43 concurrent programs, and through a user study with 30 programmers. The experiment results and user feedback show that IFIX is efficient, accurate and user-friendly.

The existing concurrency model for Java (or C) requires programmers to design and implement thread-safe classes by explicitly acquiring locks and releasing locks. Such a model is error-prone and is the reason for many concurrency bugs. While there are alternative models like transactional memory, manually writing locks remains prevalent in practice. In this work, we propose AutoLock, which aims to solve the problem by fully automatically generating thread-safe classes. Given a class which is assumed to be correct with sequential clients, AutoLock automatically generates a thread-safe class which is linearizable, and does it in a way without requiring a specification of the class. AutoLock takes three steps: (1) infer access annotations (i.e., abstract information on how variables are accessed and aliased), (2) synthesize a locking policy based on the access annotations, and (3) consistently implement the locking policy. AutoLock has been evaluated on a set of benchmark programs and the results show that AutoLock generates thread-safe classes effectively and could have prevented existing concurrency bugs.