Re: pg_atomic_compare_exchange_*() and memory barriers

On Sat, Mar 8, 2025 at 7:21 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> FWIW, I am fairly certain that any non-toy algorithm that requires a full
> memory barrier instead of just an acquire in case of a CAS failure is chock
> full of concurrency bugs.

Yeah -- off the top of my head, I can think of only two CAS patterns:
(1) retry the CAS until success (in which case the memory semantics of
a CAS failure don't matter); or (2) whoever wins the CAS is
responsible for doing some work. But, in (2), there's no reason to
expect that the "winner" has *completed* the work, so the memory
semantics of a CAS failure don't matter, since you need some other way
to say that the work has been completed.

Barriers are useful for seqlocks [1], which (IIRC) is the same
technique PostgreSQL uses for PG_STAT_BEGIN_{read,WRITE}_ACTIVITY. But
that's when you check the control (sequence) variable both before and
*after* touching the data it protects.

James

[1] https://en.wikipedia.org/wiki/Seqlock