3 ms·
...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else
by johnhamlet 13y ago
...but you can still have races with locking.
Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control.
Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.
- dbaupp 13y agoNo compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.
- johnhamlet 13y agoYou: "not every non-deterministic piece of code is a race-condition" Wikipedia: "A race condition ... is ... where the output is dependent on the sequence or timing..." Boom! Headshot!
- dbaupp 13y agoBeing nondeterministic doesn't necessarily meant the output differs. (E.g. a program that increments a global counter (with a lock) once from each of ten threads and prints the count after all threads are finished; the increments happen in a nondeterministic order but the output is always 10.)
- tinco 13y agoThe wikipedia article means the sequence or timing of the execution of the instructions in relation to each other. Non-deterministic code does not only encompass code of which the results vary with the timing of instructions relative to each other, but also code of which the results vary with the timing of instructions relative to the state of the universe or anything in it.
- noahl 13y agoBoom! Headshot! That adds nothing to the discussion and makes it feel more adversarial. It reduces the quality of discussion for no gain. Please don't do that again.
- pcwalton 13y agoI'm defining "data race" in the same way that race detectors do—concurrent access to a piece of memory without use of a synchronization primitive. Rust rules those out at compile time.
- jerf 13y agoWhat exactly is your goal here, with this reply chain you're making? No, Rust has no magical solutions to message passing order. There aren't any, because your "message A" and "message B" could well be network transactions, which will come at you in arbitrary order from two different machines. Given that there's no "solution" to this problem anyhow, what's the point of trying to attack Rust here?