MSDN Magazine - June 2008 - (Page 54)

ConCurrenCy Tools And Techniques To Identify Concurrency Issues rahul V. Patil and Boby George In order to satisfy the perpetual need for increased computing power, the hardware industry is steadily shifting toward multi- and many-core processor systems. Unlike the increased application performance attained by faster processors with higher clock speeds, performance improvements in many-core systems can only be achieved by writing efficient parallel programs. Forms of parallelism have existed in the software industry for a long time. However, creating mainstream software applications that harness the full power of parallel hardware requires significant changes from the practices designed for sequential applications. Testing parallel applications is not straightforward. For instance, concurrent bugs are difficult to detect due to the nondeterministic behavior exhibited by parallel applications. Even if these bugs are detected, it is difficult to reproduce them consistently. Further, after fixing a defect, it is difficult to ensure that the defect was truly recThis article discusses: • Problems in concurrency testing • elusive bugs and their dependencies • New tools to find the roadblocks • Best practices for designing your tests tified and not simply masked. In addition, parallelization can also introduce new performance bottlenecks that must be identified. In this article, we’ll look at testing techniques for parallel programs and present six helpful tools you can use to locate potentially serious defects. We’ll begin with the following categories of concurrency bugs: race conditions, incorrect mutual exclusions, and memory reordering. Race Conditions, Deadlocks, and More Technologies discussed: Dynamic and Static Analysis, Model Checking 54 msdn magazine A race occurs when two or more threads of execution in a multithreaded program try to access the same shared data and at least one of the accesses is a write. Harmful race conditions introduce unpredictability and are often hard to detect. The consequences of a race condition might only become visible at a much later time or in a totally different part of the program. They are also incredibly hard to reproduce. Races are avoided by using synchronization techniques to correctly sequence operations between threads. Sometimes races may be safe and intentional. For example, there could be a global flag called done, for which there is only one writer but many readers. The writer thread sets the flag to tell all the threads to terminate safely. All reader threads may be running in a loop using while (!done), repeatedly reading the flag. Once a thread notices that the done flag is set, it will exit its while loop. In most cases, this is a benign race. As we will discussed later in this article, there are tools available for detecting race conditions. However,

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.