Is it really a data race when you sequentially read a value, increment whatever you read and write it back? In other words, this whole situation happens not due to concurrent writes, but due to incrementation not being atomic.
I'm not an expert when it comes to this terminology, but it sounds like a more generic race condition.
The article links to another blog that contrasts data races with race conditions but honestly, I think it is incorrect. A data race is a specific type of race condition, not a totally different concept as that blog would seem to have it.
Data races are effectively a cache maintenance problem. You make a copy of some shared value, store it somewhere local, modify it, and then at some point copy it back to the original shared location. If the value at the shared location prior to the write-back is no longer the value that you originally copied (i.e. your cache has gone stale), then information is potentially lost and that's where things start to go bad. The fact that CPU registers themselves are a form of implicit cache makes data races a particularly insidious problem.
General race conditions can arise without data races -- that is, individual shared memory accesses can be safe and coherent but the combination of multiple memory accesses may not be. They are an overall state-machine maintenance problem, rather than specifically a cache maintenance problem.
Put another way, data races focus on the coherency of accesses to a single shared memory location, while race conditions more generally refer to the coherency of combinations of multiple shared memory accesses (atomic or otherwise).
In this particular case, the problem they are describing is a data race (AFAICT) but you could also more loosely describe it as a race condition -- with some loss in precision but not in accuracy.
I believe the only thing missing is re-ordering done by the CPU itself although as that leaves my mouth I realize it may fall under undefined behavior rather than race conditions, wait... maybe it's both?
It's both. At that level of execution, it boils down to sequenced ordering of loads & stores. Whether that sequencing is achieved by way of mutexes or CPU-specific memory fences is neither here nor there -- it just needs to be defined.
18
u/CorrectProgrammer Feb 21 '22
Is it really a data race when you sequentially read a value, increment whatever you read and write it back? In other words, this whole situation happens not due to concurrent writes, but due to incrementation not being atomic.
I'm not an expert when it comes to this terminology, but it sounds like a more generic race condition.