Chapter 13. Parallelism

This chapter introduces techniques to tackle one of the harder testing problems: deterministically reproducing multithreading race conditions. Unlike most of the other techniques presented in this book, the ones in this chapter are less likely to be used in a test-driven development scenario. Race conditions typically show up as bugs, not as behaviors that we predict during development or that we use to derive coverage. However, race-condition bugs can be some of the most frustrating for users, developers, and support people alike. Reproducing these bugs to ensure that they are fixed and stay fixed provides a significant advance in confidence for our software processes and systems. These techniques also apply quite well to system and integration tests, although every defect can be isolated to one or more units for unit-testing purposes.

Most contemporary platforms support threading either explicitly or implicitly. For example, Java was designed for threading and has a strong set of concurrent programming libraries. The Java threading and libraries were not designed from scratch or in a vacuum, however. For example, many features in the java.util.concurrent package introduced in Java 5 are based on Doug Lea’s research that inspired the RogueWave Threads.h++ libraries for C++ in the 90s.

JavaScript, in contrast, supports threads only indirectly. Operations that initiate socket communications like jQuery’s ajax() method run the I/O request on a different thread. Also, use of the JavaScript window.setTimeout() API invokes a thread in the background. Raw JavaScript addresses the issue through callbacks in asynchronous methods. jQuery improves this with the Deferred() implementation.

The principles here will apply to a number of threading environments in different languages and platforms with some level of interpretation in the details.