Testing for race condition defects in code is like looking for the proverbial needle in the haystack, according to Ben Chelf, chief technology officer of Coverity Inc. "You might see something strange, but you may not see
Now, with new concurrency defect detection capabilities in the Coverity Prevent SQS static code analyzer, developers will be about to identify race conditions and other concurrency defects earlier in the development cycle, before it gets to test, according to the company.
With the advent of multi-core hardware, developers are being pushed to develop multi-threaded applications. In multi-threaded applications, race conditions occur when two threads are trying to access the same data at the same time, which can corrupt the data.
"Developers need to develop with multiple threads to take advantage of multi-cores," Chelf said. "With single-core, it was less critical for developers to think multithreaded development. With single-threaded programming, the developer has complete control over what happens — they can see every condition and determine what will happen when you run a program."
With multithread there's a combination of what's happening in code, but it's also dependent on the platform operating system where the code is running. The operating system starts making decisions for you; it schedules the thread. If the program is not designed well, it can make the program behave differently depending on what the operating system does with the threads, Chelf said.
So while testers can exercise the system to look for race conditions, "it's almost impossible to test for all the paths in the code and interleaving threads, and developers don't have control over how threads are to be scheduled," Chelf continued. "And when you ship a program, there can still be race conditions that only hit in the field under certain circumstances. It can take weeks, months or years to trace back the problem and figure out what went wrong."
New interface, advanced analysis capabilities
The latest release of Coverity Prevent SQS introduces a new interface designed to help developers understand the complex interleavings that exist within multi-threaded applications. New advanced analysis capabilities in Prevent SQS provide analysis of 100% of these interleavings, according to Coverity.
Prevent SQS identifies race conditions statically by looking for places where data is not protected appropriately, Chelf explained.
"We get around race conditions by protecting access to data," he said. "We can make sure you're doing that in the code itself. We developed a new interface for looking into issues, and a lot has to do with the way the threads interact. You need to show the developer, 'here's how the data is treated, the number of places in the code, the number of threads,' and explain to the developer in the interface so they understand the implications of the bug and they can go back in and protect it."
In addition to identifying race conditions, Prevent SQS looks for deadlock and thread block, both concurrency defects. With deadlock, two or more threads wait for a lock in a circular chain such that the locks can never be acquired. This defect can cause the entire software system to halt. With thread block, a thread calls a long-running operation while holding a lock, preventing the progress of other threads. This type of defect can dramatically impact application performance.
Previously, there was no practical way to eliminate concurrency defects prior to testing, Chelf said. Now, he said, uncovering some of the defects prior to testing will be a time-saver.
"We've been looking at concurrency-type defects for a while," Chelf said. "It's the number one request we've heard from customers. And we anticipate how much more this will be a problem as every deployment platform is multicore and every application multithreaded. The problem will only be exacerbated."
Coverity Prevent SQS is available immediately for C, C++ and Java software projects. It is priced based on project size.