On Wednesday, 10 June 2026 22:36:59 Pacific Daylight Time Jennifier Burnett
wrote:
> An acquire barrier is meaningless in this context. An acquire barrier needs
> either a release operation or atomic operation preceded by a release
> barrier to have any semantics beyond relaxed. What exactly would you be
> establishing a happens-before relationship with in the original example?
> Assuming the call to now() is an implicit acquire barrier changes nothing
> about the semantics because there's no corresponding release for it to
> establish a happens-before relationship with. The first thread doesn't even
> have any operations other than the call to now() that the acquire barrier
> would apply to

That's a good point.

The idea was that there's a third thread that updates the clock using a
release barrier, but that synchronises only with that particular thread. The
two threads doing a load-acquire don't synchronise with each other.

The barrier the Linux kernel uses is stronger than acquire for loads:
smp_rmb() is like acq_rel for loads, but does not affect writes at all. IIUC,
this could allow an older store from this thread that preceded the now() call
to remain unfinished while a younger one following the now() [potentially
including the result from it] to finish and become visible to other threads.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.