>Gary Karasiuk recently did a good presentation on Multi Threading for the Web Tools Platform committers. While I agree with much of the information there is some I think from an adopter and design stand point is a little over kill. Personally I’m not a fan of making an object Immutable with the final qualifier. With that said, I do agree with much of the other information.
One question I asked, was if there was any research that had been done for this presentation on how one can go about testing for concurency issues? They had not looked into unit testing for these issues, yet. I know that in Robert Martin’s (aka Uncle Bob) book, “Clean Code” they devote a couple of chapters to it. They recommend many of the items that Gary suggested plus several more. One testing framework that they did mention, that works with your existing Junit tests, is ConTest. I have not reviewed or used this yet, mainly because I try to avoid threading unless it is absolutely necessary. However, ConTest does have some information on how to use it with your Eclipse Plugin Tests to help detect and test for various concurrency issues.
Personally, I think threading is being over used most of the time. Just because it can be used does not necessarily mean it should be used. Also, as outlined in Clean Code, there is not enough seperation between the threading code and the non-threaded code. In many cases this gets mixed together, and becomes a nightmare to maintain and debug when issues occur. So my general rules:
- Only implement threading if you absolutely need it.
- Keep your threaded code short, avoid long running threads.
- Write Unit Tests for your threaded code.
- Test your code on multiple target platforms. Different JVM’s and Operating Systems handle threading differently. What works on one system may fail on another.
Testing threaded code is a pain. Just look at all the concurrency issues that can happen during testing the Launching and Debugging framework. In XSL Tools, we have one test that periodically fails, and it’s due to testing the Launching of XSL Transformations. This is a multi-threaded process and is a pain to debug. Sometimes it works, sometimes it doesn’t during the test runs.
If a test is randomly failing, you may have a concurrency issue that is causing the failure. These types of issues are madenning to debug. So unless you need threads, avoid them. Use them when they really provide a benefit, and use them for short durations. The longer the duration a thread or the more it spawns it’s own threads, the more likely you are to run into concurrency issues.