Re: [PATCH 2/2] rust: sync: atomic: Add atomic operation helpers over raw pointers

[Boqun Feng <boqun.feng@gmail.com>]

On Wed, Jan 21, 2026 at 01:07:34PM +0000, Alice Ryhl wrote:
> On Wed, Jan 21, 2026 at 08:51:48PM +0800, Boqun Feng wrote:
> > On Wed, Jan 21, 2026 at 01:36:04PM +0100, Marco Elver wrote:
> > [..]
[...]
> > 
> > Note that it also applies to atomic_read() and atomic_set() as well.
> 
> Just to be completely clear ... am I to understand this that READ_ONCE()
> and the LKMM's atomic_load() *are* the exact same thing? Because if so,
> then this was really confusing:
> 
> > my argument was not about naming, it's
> > about READ_ONCE() being more powerful than atomic load (no, not because
> > of address dependency, they are the same on that, it's because of the
> > behaviors of them regarding a current access on the same memory
> > location)
> > https://lore.kernel.org/all/aWuV858wU3MeYeaX@tardis-2.local/
> 
> Are they the *exact* same thing or not? Do you mean that they are the
> same under LKMM, but different under some other context?

Right, they are the same thing under LKMM when used for inter-thread
synchronization when they are atomic. But when READ_ONCE() (and
__READ_ONCE()) used on types that are larger than machine word size,
they are not guaranteed to be atomic, hence semantics-wise READ_ONCE()
firstly guarantees "once" (volatile and no data race with WRITE_ONCE())
and then on certain types, it's atomic as well.

* In the case that we need atomicity, we should just use atomic_load().
* In the case that we don't need atomicity and no data race, we can just
  use read_volatile().
* In the case that there is a non-atomic concurrent write, that suggests
  we have a bug in C code or we simply should have some other
  synchronization. Or if we believe the conncurrent write has at last
  per-byte atomicity, then we can have `READ_ONCE()`-like function that
  returns a `MaybeUninit` to bear the possible tearing.

Regards,
Boqun

> 
> Alice