Preventing Concurrency Bugs from Causing Harm, Automatically
In today’s world, where concurrency is ubiquitous, we see many different kinds of concurrency issues causing problems in our software. Some people suggest to avoid low-level concurrency issues altogether by moving away from shared memory, threads, locks, and other low-level concurrency constructs. They suggest that actors and event loop systems are more high level and less prone to concurrency issues.
Unfortunately, actor programs and event loop systems such as Node.js do still suffer from concurrency bugs .
Let’s Prevent Concurrency Bugs from Causing Harm
In the last decade, researchers developed mechanisms that prevent concurrency bugs from manifesting [2, 3, 4] . This means, even so our programs are not as correct as we would like them to be, a runtime system can prevent major harm from occurring.
The problem with current approaches is that they are impractical in one way or another. Typically, they have high run-time overhead. The techniques for detecting concurrency issues such as race conditions and message interleaving issues can slow down systems too much, which makes the systems impractical for use in server applications.
Applying Dynamic Language Implementation Techniques
Though, I believe we can change this by applying ideas from dynamic language implementations to the problem of race detection [5, 6].
In the CaMELot project, we want to “Catch and Mitigate Event-Loop Concurrency Issues”. And, we are looking for help!
If you are interested in concurrency issues, compilers, dynamic language implementation techniques, race detection, and similar techniques, join me in developing new techniques that make it more practical to prevent concurrency bugs from causing harm, automatically. Of course, while we are at it, we naturally want to give developers the necessary tools to fix their bugs, too.
And if you came across this blog post because you have concurrency issues in the application you’re working on, well, in this project we want to hear such stories, too. After all, we need ways to test our ideas, ideally on a collection of real-world example bugs.
For our experiments, we’ll build on top of the GraalVM. With its Truffle-based interpreters , it provides a convenient and efficient platform. Having worked on Truffle interpreters since mid-2013, I also got a bit of experience working with it myself. SOMns and Graal.js are the candidates for experimenting with the ideas.
As mentioned above, we are looking for bug reports from production systems as part of this project. We’ll use them to evaluate our techniques. To find concurrency bugs, we’ll reach out to the communities of Node.js, Akka, Vert.x, Erlang, Orleans, and similar systems to have an informed view on common issues, issues that are hard to diagnose, and issues that cause the biggest problems.
Here at the Programming Languages and Systems group of the University of Kent, we currently have the following open positions:
If you have any questions, wonder whether you qualify, or are simply curious, please contact me. I am also happy to answer questions via @smarr on Twitter.