read/write volatile

Posted Jan 10, 2026 20:13 UTC (Sat) by comex (subscriber, #71521)
In reply to: read/write volatile by plugwash
Parent article: READ_ONCE(), WRITE_ONCE(), but not for Rust

That’s correct, but not actually applicable to Rust, because Rust doesn’t allow atomics to be implemented with a global lock, unlike C++ and C. Instead, on targets that don’t natively support atomics, Rust just makes the atomic APIs unavailable. It’s one of those tradeoffs where Rust is willing to accept slightly less portability in exchange for a nicer programming model.

to post comments

read/write volatile

Posted Jan 11, 2026 17:49 UTC (Sun) by garyguo (subscriber, #173367) [Link]

Note that the kernel unconditionally provide 64-bit atomic operation to all archs, and in archs that doesn't support native atomics on 64-bit integers, they are implemented using locks. This means that using `READ_ONCE()` on u64 for atomic ops is incorrect (it needs to be a `atomic64_read()`).

`READ_ONCE` on u64 might still be useful is you just want to read the value in a data-race-free way and you don't care about atomicity (i.e. allow the read to tear). However this is yet another reason I don't want people to just use `READ_ONCE()` for atomic ops on Rust side -- it's just not intuitive which semantics is desired.