4 ms·
`unsync_load` reads the memory as if it were a normal field (no atomic operation). The `std` atomic types already provide `get_mut` which gives access to the "r
by carllerche 7y ago
`unsync_load` reads the memory as if it were a normal field (no atomic operation). The `std` atomic types already provide `get_mut` which gives access to the "raw" field when the caller has a mutable reference to the atomic. The mutable access guarantees there are no concurrent threads that can access the field, so it is safe.
The `unsync_load` is used because, at that point, two things are guaranteed:
- The only thread that mutates the field is the `unsync_load` caller
- All other threads will only read from that field.
Because of this, we can just do a "plain old" access of the field w/o the atomic overhead.
As for whether or not it should be in `std`, I don't know. It probably could, but it doesn't have to. It's a pretty "advanced" access strategy.
- dunkelheit 7y agoWhat is the difference with Ordering::Relaxed?
- ComputerGuru 7y agoOrdering::Relaxed guarantees atomicity (but not coherence). On 32-bit or 64-bit platforms, a (aligned) 32-bit read or write will always be atomic anyway.
- dunkelheit 7y agoWhat do you mean by coherence? If it is the property that all updates to a single memory location are seen in a consistent order by all threads then Relaxed guarantees that.
- wilsonthewhale 7y agoit doesn't. From cppreference (whose model Rust roughly follows): "Relaxed operation: there are no synchronization or ordering constraints imposed on other reads or writes, only this operation's atomicity is guaranteed"
- dunkelheit 7y agoStill I think I am correct. The docs (https://doc.rust-lang.org/std/sync/atomic/enum.Ordering.html#variant.Relaxed https://doc.rust-lang.org/std/sync/atomic/enum.Ordering.html...) point to https://llvm.org/docs/Atomics.html#monotonic https://llvm.org/docs/Atomics.html#monotonic which states that "It essentially guarantees that if you take all the operations affecting a specific address, a consistent ordering exists." which is what I've said.
- ComputerGuru 7y agoYes, a consistent ordering exists but that ordering isn’t necessarily what you think or want it to be. The consistency is present based off the order the reads and writes were executed in; you’ll never read back a value that wasn’t at some point stored there. Which can happen with non-atomic reads/writes, where you’ll read part of one write and part of the next. Reads can still be reordered before writes, as no memory barriers are issued.
- dunkelheit 7y agoWell that doesn't contradict anything that I have said :) My question remains - what do you mean by coherence? I argue that it is precisely the property that there is a consistent order of operations a single memory memory location so you can't say that Relaxed operations don't satisfy coherence.
- frankenbee 7y agoHm
- gpderetta 7y agoYou are correct. IIRC Coherency is the only property of relaxed atomic operations, as opposed of plain load/stores where concurrent modification and access is just UB.
- comex 7y agoAn assembly-level read or write will always be atomic anyway, and in fact a relaxed atomic read/write typically compiles down to the exact same assembly as a normal read/write. However, there are compiler optimizations that can break atomicity, such as splitting accesses into multiple parts; using (relaxed) atomics instructs the compiler not to perform those optimizations.
- carllerche 7y agoRelaxed ordering impacts the compiler. There are a number of optimizations it cannot make. I am not sure exactly what those are, but it is measurable.
- dunkelheit 7y agoProbably some reordering? Would be interesting to compare generated assembly.
- carllerche 7y agoI believe there are some LLVM "bugs" with regards to Relaxed ordering. I don't know the specifics.
- CodesInChaos 7y agoThe only forbidden optimization I could come up with is: x = load-relaxed(a) ... f(x) cannot be turned into x0 = load-relaxed(a) ... x1 = load-relaxed(a) f(x1) while this would be possible with normal memory access. so under register pressure the compiler would be required to spill something onto the stack instead of just reloading `x` from the original location.
- carllerche 7y agoLast time I spoke about this topic w/ the rust compiler devs, they mentioned there were some LLVM "bugs" with regards to optimizations and Relaxed, as in LLVM is too conservative.
- likeliv 7y agoIs that not an undefined behaviour? Can't you get some values "out of thin air" (partial updates of some bits.) Or some intermediate values? (For example, can the compiler decide to use this memory location to store some unrelated temporary result, as it knows it will erase it soon with a final value and that no other threads is supposed to access this)
- carllerche 7y agoThe compiler cannot use the contents of an `UnsafeCell` for temporary storage. In general, `UnsafeCell` is how data can be shared across threads without synchronization.
- CodesInChaos 7y agoI thought `UnsafeCell` is only exempt from the aliasing rules, not the memory model? I.e. the compiler can use it as it wants, if it can prove that it's not accessed in the meantime (which can be difficult without relying aliasing rules, but possible if the code is simple enough)
- carllerche 7y agoTo be honest, I'm not entirely following what you see as the danger. The compiler can't generate code that randomly goes and writes at pointer locations.
- BubRoss 7y agoIn x86 at least, 32 bit loads and stores are done atomically already.
- likeliv 7y agoI know rust is not C or C++, but we are not programming in x86 assembly, but for the language "abstract machine". And if the compiler infer that this memory location is not used by other threads because we don't use an atomic operation, it can perform optimizations that could result in subtle bugs. That's what undefined behaviour is. Although in this case, I guess this is probably fine since the non-atomic read can't race with a write.