Data Races with Increment and Volatile

Dec 1, 2010 at 3:44 PM

Nice overview about parallel and concurrent programming!
I read all units and found the following issues.
In unit 2a “Data Races And Locks” page 8 says a integer increment is not atomic (balance++;). The .NET JIT compiler translates the increment into the atomic instruction “inc dword ptr”. But on a multi-core computer there can be even a data race with this atomic increment because of multiple copies of the integer variable in data caches.
Even with a volatile declaration of the integer variable the data race can occur. I think the sentence in unit 5a Threads on page 31 that volatile flushes caches is not correct.

Dec 2, 2010 at 9:07 PM

Hi Steffen,

Thanks a lot for your feedback, you bring out good points. The wording in unit 2a about an integer increment not being atomic needs more clarification. In the hardware, an instruction is "atomic" if it is all or nothing. The hardware guarantees that no interrupt, and thus no context switch, can happen between the two accesses involved in the increment. When we used the word "atomic" we meant that the effects of the increment do not happen as a logical unit in a multi-threaded program. When running on a multicore, other threads can interleave between the two accesses, as you pointed out.

Also, the way we have defined "data races" it precludes some concurrency bugs that are commonly referred to as "races". Our definition is akin to the definition used by the Java Memory Model (http://www.cs.umd.edu/~pugh/java/memoryModel/). As you mention, if the variable is declared volatile, then we will happily say that you have avoided the data race on that variable when the program concurrently increments that variable - however, you still have the bug where you might miss an increment (some call it "atomicity violation" - as the programmer might have intended the increment to happen "atomically" - as one logical unit - similar to an interlocked increment instruction).

madan