3 ms·
> I'll also note that using AcqRel semantics is not provided by the Rust version of compare_exchange_weak (perhaps a nit on TFA's assertion that Rust adopts the
by spinlocker 5y ago
> I'll also note that using AcqRel semantics is not provided by the Rust version of compare_exchange_weak (perhaps a nit on TFA's assertion that Rust adopts the C++ memory model wholesale), so if acquire to lock the spinlock is not adequate, it's likely it would need to go to SeqCst.
Is this true? AcqRel seems to be accepted by the compiler for the success ordering of compare_exchange_weak.
- raphlinus 5y agohttps://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.html#method.compare_exchange_weak https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.h... It's accepted by the compiler, but if provided, it compiles to a panic.
- spinlocker 5y agoOn the page you linked panics are only mentioned for load and store and the code below seems to work just fine? let x = atomic::AtomicU32::new(0); x.compare_exchange_weak( 0, 1, atomic::Ordering::AcqRel, atomic::Ordering::Relaxed).unwrap(); println!("{}", x.load(atomic::Ordering::Relaxed));
- raphlinus 5y agoAh, you're right. I was using the same ordering for success and failure. It is possible to use AcqRel in the success case.
- spinlocker 5y agoLooks like in C++ memory_order_acq_rel is treated like memory_order_acquire when it's a load and memory_order_release when it's a store. I would argue that this isn't really a difference in memory model but a difference in API.
- raphlinus 5y agoI agree. Sorry for the misdirection - the panic is something I observed when I was experimenting with it, and I misinterpreted it.