• 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. 

Better Languages

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.

Better Libraries

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.

Conclusion

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.