The Race To Development Errors
Page 1 of 1
You could drive a truck through some of the defects that can creep into the software development process.
Among the most difficult to detect is something called a Race Condition. When a Race Condition exists, shared data is accessed by multiple concurrent threads without proper data access protection which could lead to data loss, corruption or crashes.
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.
"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."
Coverity claims that their solution is the first solution capable of identifying dangerous Race Conditions in software.
"Based on currently available information, we're not aware of any other commercial tools that statically detect race conditions that involve access to shared memory by multiple threads," Chou said.
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.
"Weve 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 theyre more common than many programmers might believe.
"A race condition in a web application can result in a users 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."