11
Conclusions  Patient says, “Doctor, doctor, it hurts when I do this.”  Doctor replies, “Then don’t do that!” ☺  Natural to apply this to concurrency  But must be exceedingly careful in the details  Makes strong guarantees, but does not promise the world  Never allows interleavings that were not already possible  But may cause deadlocks by over-constraining execution space  Uses some heuristics, but excellent results in practice  Overheads too low to reliably measure  Produces small, simple, understandable patches  Completely eliminates detected bugs in targeted class

12
Abstract Fixing software bugs has always been an important and time-consuming process in software development. Fixing concurrency bugs has become especially critical in the multicore era. However, fixing concurrency bugs is challenging, in part due to non-deterministic failures and tricky parallel reasoning. Beyond correctly fixing the original problem in the software, a good patch should also avoid introducing new bugs, degrading performance unnecessarily, or damaging software readability. Existing tools cannot automate the whole fixing process and provide good-quality patches. I will present AFix, a tool that automates the whole process of fixing one common type of concurrency bug: single-variable atomicity violations. AFix starts from the bug reports of existing bug-detection tools. It augments these with static analysis to construct a suitable patch for each bug report. It further tries to combine the patches of multiple bugs for better performance and code readability. Finally, AFix's run-time component provides testing customized for each patch. Experimental evaluation shows that patches automatically generated by AFix correctly eliminate six out of eight real-world bugs and significantly decrease the failure probability in the other two cases. AFix patches never introduce new bugs and have similar performance to manually-designed patches.