Re: pg_atomic_compare_exchange_*() and memory barriers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_atomic_compare_exchange_*() and memory barriers
Date
Msg-id tsznvs62vmho3qlswushbfy35gzkcyrv6bxk67g2pfbjpruepj@3ts2xiafyxxb
Whole thread Raw
In response to Re: pg_atomic_compare_exchange_*() and memory barriers  (Pavel Borisov <pashkin.elfe@gmail.com>)
List pgsql-hackers
Hi,

On 2025-03-07 21:08:34 +0400, Pavel Borisov wrote:
> On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov <aekorotkov@gmail.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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Parallel heap vacuum
Next
From: Andres Freund
Date:
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers