Re: pg_atomic_compare_exchange_*() and memory barriers

Hi,

On 2025-03-07 21:08:34 +0400, Pavel Borisov wrote:
> On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > Yes, there surely should be a memory barrier on another side. But
> > does __ATOMIC_SEQ_CST works as a barrier for the regular read/write
> > operations on the same side?
> According to a reference posted by Andres [1]:
> "Within a thread of execution, accesses (reads and writes) through
> volatile lvalues cannot be reordered past observable side-effects
> (including other volatile accesses) that are separated by a sequence
> point within the same thread, but this order is not guaranteed to be
> observed by another thread, since volatile access does not establish
> inter-thread synchronization."

How is volatile relevant here?

> Also: "as soon as atomic operations that are not tagged
> memory_order_seq_cst enter the picture, the sequential consistency is
> lost"

Sequential consistency is lost, but that does *NOT* mean that acquire/release
guarantees that are also guaranteed by ATOMIC_SEQ_CST are lost.

Greetings,

Andres Freund