There is no requirement that an acquire barrier be preceded by a release
barrier. All an acquire barrier means is "ensure that no read operation
after this instruction can be reordered before this instruction".
Similarly, a release barrier means "ensure that all pending write
operations are completed before passing beyond this instruction".

It's much clearer if you break it out into explicit memory barrier/fence
instructions. One thing that's misleading is that the acquire/release
naming makes people think "I'm acquiring some data / I'm releasing some
data" - which isn't the case. It's named after mutex/critical section
behavior - acquiring the lock vs. releasing the lock.

Acquiring a lock doesn't require you to release a lock before you do it for
the first time.

On Wed, Jun 10, 2026 at 10:37 PM Jennifier Burnett <jenni_at_[hidden]>
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
>
> On 11 June 2026 01:37:42 BST, Thiago Macieira via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >On Wednesday, 10 June 2026 16:24:30 Pacific Daylight Time Simon Cooke
> wrote:
> >> If you don't want that, you need acquire semantics, which will prevent
> the
> >> write from down after the timestamp() call in #2
> >
> >This is the essence of the argument: reading from the monotonic clock
> should
> >be an acquire barrier. The Standard does not say it is, but I think it
> should.
> >
>