4 ms·
That's not true, Rust permits opt-in data races in safe code.
by detrino 11y ago
That's not true, Rust permits opt-in data races in safe code.
- dbaupp 11y agoIf what you say is true, it's a bug: there should only be a risk of data races if `unsafe` is used. Do you have a code example?
- veddan 11y agoI'm guessing he refers to atomics with relaxed memory ordering. That doesn't give much in terms of guarantees beyond atomicity and no "out-of-thin-air" values. I'm not sure of whether this is a data race under Rust's definition though.
- detrino 11y agoRust doesn't get to redefine "data race".
- pcwalton 11y agoIt doesn't. We use the same definition of "data race" as tools like Thread Sanitizer and Eraser do.
- detrino 11y agoFrom tsan documentation: "A data race occurs when two threads access the same variable concurrently and at least one of the accesses is write"
- pcwalton 11y agoThat's right, and Rust bans that. The definition of "concurrently" typically means "without synchronization in between". An atomic access is by definition a form of synchronization.
- detrino 11y agoRelaxed access of atomics performs no synchronization.
- Gankro 11y agoIt guarantees that the value read was some value that was in the variable at some point. e.g. it prevents a value that toggles from 3 to 5 being read as 117. It also prevents writes from being eaten (e.g. an increment always actually occurs). This necessitates some level of synchronization.
- Manishearth 11y ago(It also guarantees happens-before for a given thread, so if a thread changes it from three to 5 and other threads are not changing it back, that thread will never read a 3 again. This also needs some level of synchronization)
- burntsushi 11y ago"Relaxed atomic operations can be reordered in both directions, with respect to either ordinary memory operations or other relaxed atomic operations. But the requirement that updates must be observed in modification order disallows this if the two operations may apply to the same atomic object. (The same restriction applies to the one-way reordering of acquire/release atomic operations.)" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n233... There is a lot more explanation here that should cast some light on the situation: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html#unordered http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n248...
- Manishearth 11y agoAnd the line right next to that: > C++11 standard officially bans data races as undefined behavior. Relaxed access of atomics is not UB in C++, that would be ridiculous. Clearly one of these two sentences is wrong or imprecise; I would bet it's the first one.
- burntsushi 11y agoThere is definitely something special going on with relaxed updates though. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html#unordered http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n248... Also https://news.ycombinator.com/item?id=9796245 https://news.ycombinator.com/item?id=9796245 I think your initial suspicion is right. The next section: "There are several possible definitions of a data race. Probably the most intuitive definition is that it occurs when two ordinary accesses to a scalar, at least one of which is a write, are performed simultaneously by different threads. Our definition is actually quite close to this, but varies in two ways:" ... "Instead of restricting simultaneous execution, we ask that conflicting accesses by different threads be ordered by happens-before. This is equivalent in simpler cases, but the definition based on simultaneous execution would be inappropriate for weakly ordered atomics." continues at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html#races http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n248...
- dbaupp 11y agoThe atomicity guarantees it's not a data race.
- detrino 11y agoFrom wikipedia: A race condition or race hazard is the behavior of an electronic, software or other system where the output is dependent on the sequence or timing of other uncontrollable events. Example: https://gist.github.com/anonymous/eb72f1091bd1592df552 https://gist.github.com/anonymous/eb72f1091bd1592df552 Output: $ for i in {0..10000}; do ./race; done | sort | uniq 0 1
- dbaupp 11y agoAh, that's a race condition, something that Rust doesn't protect against in general (it's fairly difficult: whether a piece of non-determinism is a race condition depends on the semantics the programmer desires). A data race is more specialised, and we try to be careful to use "data race" when discussing this aspect of Rust. http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 has a fairly good discussion of the generally accepted definition of data race.
- steveklabnik 11y ago"Data race" is a more specific term than "race condition." See http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 for more. But the TL;DR is: A data race happens when there are two memory accesses in a program where both: * target the same location * are performed concurrently by two threads * are not reads * are not synchronization operations I would argue you have a race condition but not a data race.
- deleted 11y ago[deleted]