4 ms·

> I'd say data races are race conditions, but not all race conditions are data races. This is not the case according to the article. In the article, transfer4

by javert 7y ago

> I'd say data races are race conditions, but not all race conditions are data races. This is not the case according to the article. In the article, transfer4 is a data race but not a race condition. Your example with T1 and T2 is a race condition and a data race. Your example with a = a + 1 is neither a race condition nor a data race since there is no concurrency. It's probably possible to argue that the terms should be defined differently to match the formulation you have instead of the author's. After all, definitions are created by people to help our thinking and we can change them or refine them. But I suspect that would be very a difficult argument to make in a compelling way.

didibus 7y ago
Maybe I didn't understand the article properly then. Their example of a data race is account.activity = true; Which two threads could perform concurrently. Now from my understanding, the issue is that the hardware, OS, runtime and compiler might not guarantee that this assignment is atomic. Thus if two threads were to perform it concurrently, the result would be undefined, in that maybe the value ends up being true, or maybe it ends up corrupted, or maybe it is still false, or it will eventually be true, but for a while, if you read back the value it would still be false, etc. Edit: Also I don't think you understood my example. When I lay out T1 and T2, I'm talking about two threads concurrently executing a = a + 1;. Which is a data race, by their definition. But I'm saying that the issue with data races are that they can lead to race conditions at the assembly level. Thus a data race is really just a race condition at the assembly or even hardware level.
jacinabox 7y ago
I'm starting to be convinced that data races don't matter if the variable being raced is in the machine word size.
- bshanks 7y ago
  It depends on context. It's true that many CPUs provide atomicity for aligned accesses of the machine word size. However, the C/C++11 standard defines data races to be undefined behavior, so a data race in a C program still matters.

by javert 7y ago

didibus 7y ago

Maybe I didn't understand the article properly then. Their example of a data race is account.activity = true; Which two threads could perform concurrently. Now from my understanding, the issue is that the hardware, OS, runtime and compiler might not guarantee that this assignment is atomic. Thus if two threads were to perform it concurrently, the result would be undefined, in that maybe the value ends up being true, or maybe it ends up corrupted, or maybe it is still false, or it will eventually be true, but for a while, if you read back the value it would still be false, etc. Edit: Also I don't think you understood my example. When I lay out T1 and T2, I'm talking about two threads concurrently executing a = a + 1;. Which is a data race, by their definition. But I'm saying that the issue with data races are that they can lead to race conditions at the assembly level. Thus a data race is really just a race condition at the assembly or even hardware level.

jacinabox 7y ago

I'm starting to be convinced that data races don't matter if the variable being raced is in the machine word size.

bshanks 7y ago
It depends on context. It's true that many CPUs provide atomicity for aligned accesses of the machine word size. However, the C/C++11 standard defines data races to be undefined behavior, so a data race in a C program still matters.