You could drive a truck through some of the defects that can creep into the software development process.

Code analysis vendor Coverity is now claiming that it has a solution for detecting Race Conditions. Coverity claims that their detection capabilities in their Coverity Prevent code analysis solution will identify concurrency issues that lead to Race Conditions. By detecting them the hope is to be able to enable software developers to eliminate the problem.

Coverity's Chief Scientist, Andy Chou explained to InternetNews.com that Race Conditions are difficult to detect because they depend on the specific timing and ordering of events in order to occur.

"Most of the time, a program with a race condition can appear to run normally," Chou said. "Only when a certain sequence of events occurs in a particular order does a race condition manifest in the form of data corruption. This can cause a system to behave strangely or crash at unpredictable times. Developers find that when they go to reproduce a race, everything seems to run normally because they cannot reproduce the exact circumstances that cause the race to occur. Often they resort to guessing what is wrong and reviewing the code manually."

Other code analysis vendors disagree.

Both Klocwork and Fortify claim that their respective solutions can identify Race Conditions as well. Klocwork and Fortify both have competitive code analysis solutions.

"We’ve been detecting race conditions since we released our first product about four years ago," Brian Chess, Fortify's founder and chief scientist told InternetNews.com.

"Klocwork does indeed spot race conditions, and has done so for quite a while," Gwyn Fisher, Klocwork's CTO told InternetNews.com. "A typical race condition that we spot centers around concurrent modification of data by two or more threads in a multi-threaded application. This capability uses inter-procedural analysis to follow the trail of potentially modifiable data from any defined thread entry point to the point of modification."

Regardless of who was first and who followed, race conditions are becoming increasingly problematic as multi-core processors and multi-threaded are applications are becoming increasingly pervasive.

"CPUs have been moving to multiple cores instead of higher clock speeds because of physical limitations. This is a fundamental change," Coverity's Chou explained. "In the past, all software would benefit from increased clock speeds, but now only software specifically written to take advantage of multiple cores can benefit. This means that more and more programs will be multi-threaded and thus prone to having race conditions."

The risks of race conditions are also non-trivial and should be taken very seriously by developers. According to Fortify's Chess they’re more common than many programmers might believe.

"A race condition in a web application can result in a user’s data being shown to another user. A race condition in an online game could allow a player to cheat by effectively being in more than one place at the same time," Chess said. " To make matters worse, race conditions can be really hard to track down because the cause of the problem and the resulting symptom are often far removed."

Oh and don't think that any one development approach is any less prone to race conditions either. Apparently they're all equally at risk.

"Almost all languages and architectures allow for multi-threading or another form of concurrency," Coverity's Chou said. "Race conditions can occur in all of these systems."


Adobe to Open Source Messaging Protocols
Sun Opens Up UltraSPARC T2 Core