Find out what dangers race conditions in general and C++0x data races in particular pose to your concurrent code, as well as the strategies for avoiding them.
by Anthony Williams
September 10, 2009
ace conditions are an inherent part of parallel programming. A race condition exists any time a program's behavior may depend on the relative ordering of events on separate threads. In the vast majority of cases, race conditions are harmless—the program works regardless of which thread gets a lock first, or which thread processes a chunk of data. In some cases, however, race conditions can cause problems.
The main danger with race conditions is that by their very nature they are timing dependent. This becomes problematic when one thread executes a particular piece of code while another thread is executing a different piece of code. If the pieces of code in question are very small (only one or two CPU instructions, for example) and occur very rarely, then the race condition might not show up very often, and you may miss it entirely during testing. In fact, the conditions necessary for the problem to occur may not manifest at all during testing.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
ace conditions are an inherent part of parallel programming. A race condition exists any time a program's behavior may depend on the relative ordering of events on separate threads. In the vast majority of cases, race conditions are harmless—the program works regardless of which thread gets a lock first, or which thread processes a chunk of data. In some cases, however, race conditions can cause problems.
