email article printer friendly get the code more resources

Identify Problems with Testing Multithreaded Code
Recognize the issues that create the need for unit testing in a multithreaded Java environment
by Robert W. Nettleton

Posted November 26, 2003

Thread safety—it's a term we use to describe Java code that can be used safely by multiple concurrent threads of control in a program. There are many techniques that must be used in a concurrent application to ensure correctness. One of the most challenging tasks a programmer can face is to fix threading bugs in already existing code. Making someone else's code thread-safe is quite a daunting task. Deadlocks and race conditions provide truly challenging work for any developer. There are many problems that developers face when working on concurrent code. These problems deal with issues that stem from the facts of concurrent code itself, and the difficulties associated with reproducing bugs and errors. Another set of problems then occurs: how does a team of developers keep concurrency bugs from reappearing in their code?

I faced these very issues on a recent project in which I was tasked with fixing some serious threading problems in a given component that I had inherited from another developer. Being a believer in the power of test-first coding, I would develop tests alongside each new feature, which enabled me to modify code quickly while assuring a certain base level of quality. For simple functionality tests, these tests were reasonably easy to write. I would instantiate a given class, feed it simulated data, and vary the correctness of the outputs. For concurrency problems, however, I needed something more than that. I needed a small framework for running given tasks concurrently, and support for checking the pass/fail condition of a given set of concurrent tasks. Let's begin looking at that framework here.

If you're currently developing or maintaining concurrent Java applications, then read on. In this first installment we'll begin by discussing the inherent problems with developing and testing multithreaded code, including the challenges of duplicating bugs that occur only when there is more than one thread of control executing. Then in the next installment we'll look at a method that is very useful in the development and maintenance of concurrent Java software: test-first coding. I'll provide some examples of how to use test-first in a multithreaded scenario, including helpful strategies on using these techniques in your own projects. Then we'll conclude in the third installment with a set of best practices for testing concurrent code as well as some limitations. These best practices can be helpful when developers are implementing unit tests during the development cycle. When test-first coding is used, it is possible to guarantee a degree of thread safety that ordinary development methodologies don't allow for.

Confront the Hurdles
If you're the developer of a library shared by multiple applications, or if you're tasked with maintaining one, you probably already have an inkling of the complexity involved in creating and maintaining thread-safe code. Many of the problems arise because developers are taking educated guesses at the correctness of their code. Developers might not envision their component being used in a multithreaded environment. Another problem that could arise is what I call the hidden thread bug: a developer properly maintains a thread-safe object, synchronizing access to all shared mutable data, but the object maintains references that are not thread-safe. Using a static hashmap to hold references to objects that are expensive to create serves as an example. Many times it will not be obvious to developers that this situation creates a possible threading nightmare that can allow deadlocks, race conditions, and other bugs that can be very difficult to duplicate.