Understanding Data Races vs. Race Conditions

[francescopedronomnys]

Hi @AvdLee, in the Sendable module it's not clear to me why you define the first example a data race and the second a race condition.
Even in your definition you are simply swapping "data" with "memory", but aren't data and memory the same thing?
If I correctly understand what you are trying to communicate you are calling a data race when multiple threads are cuncurrently doing operations that look atomical (+= 1) but are not, and a race condition when two atomical operations (await counter.increment() and await counter.getValue()) are executed in the wrong order because of a logical problem (e.g. a scheduling problem in the race condition example).

Maybe it's just the initial example for data races that is not clear to me because I'm familiar more with Swift Cuncurrency than with GCD.
Looking at how you are resolving it using GCD I see that you made two changes: first you changed the order of execution of += 1 operations from concurrent to serial, and then you also syncronized how you read the result.
This brings up another question: the initial data race example was problematic only because a cuncurrent increment was executed, or was the problem also related to cuncurrency between increments and the final print's statement read operation?

If both issues were present in the first example, is it correct to consider the first as a data race and the second a race condition?
Please let me know if my understanding is correct.

[AvdLee]

In short: Data races cause exceptions, race conditions unexpected outcomes.

It's definitely GCD experience that made this more clear for me, Strict Concurrency prevents a lot of these cases. So I get that it's harder to understand if you're less familiar with GCD.

This brings up another question: the initial data race example was problematic only because a cuncurrent increment was executed, or was the problem also related to cuncurrency between increments and the final print's statement read operation?

When a read of the same data that's being written happens at the same time, a crash occurs. It's the combination of a concurrent increment and read operation that could happen at the same time. Whether they happen at the same time depends on scheduling. This is why actors solve this issue: it prevents a read from happening at the same time as a write, since it isolates access.

Let me know if this clarifies things!

[francescopedronomnys]

Clear now, thanks