We, as developers, have a problem. CPUs will continue to have more cores, and each core is not going to be any faster. The only way to write faster applications is to write multithreaded code, which has two challenges:
- Multithreaded code is complex to write and think about.
- Multithreaded code is difficult to test.
From what I’ve seen, people are pursuing 4 approaches.
If languages are the whole answer, the language has to make it impossible to write multithreaded bugs, otherwise you only address the first problem (the complexity).
Erlang is one such language that removes whole class of multithreaded bugs. Erlang’s approach is to isolate the threads, and give them a way to pass messages to each other. However programming in Erlang is awkward and arguably it makes the code more complex.
Other languages, like Clojure and F#, take a different approach and make it easier to write and deal with multithreaded issues, however they don’t prevent you from writing multithreaded bugs. These languages do not address the whole problem as you still need a way to test the code.
Microsoft has a library for .Net called Parallel Task Library to make it easier to write multithreaded code. Need to operate on each element in an array? Use the Parallel.For() method. This library makes it easier to think and write multithreaded code, but it doesn’t make it any easier to test.
Static Code Analyzer
Java has a static code analyzer that is able to find multithreading bugs called FindBugs. It looks at your code and reports any code that will cause multithreaded bugs. This would address the second issue, because it, in theory, reports all threading bugs. It doesn’t however address the first issue, making the code easier to write.
Testing with Deterministic Threads
Microsoft is going in a different direction. They are working on something called CHESS that makes your unit tests find multithreaded bugs. It does this by taking over the scheduler and sysmatically repeating each test, weaving the threads differently each time to exercise every possible way the scheduler could run the code. However it requires us to to write a set of tests that finds *all* the threading bugs. Since it is common to write unit tests with less than 100% coverage, a code coverage tool should be used to write more tests.
The good news is that there appears to be a variety of approaches to the problem and the whole answer will likely involve a combination of language or library enhancements and analyser or testing enhancements that are already in the works.