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

static inline bool
pg_atomic_compare_exchange_u64_impl(volatile pg_atomic_uint64 *ptr,
                                    uint64 *expected, uint64 newval)
{
    AssertPointerAlignment(expected, 8);
    return __atomic_compare_exchange_n(&ptr->value, expected, newval, false,
                                       __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}

According to the docs __ATOMIC_SEQ_CST enforces total ordering with all other __ATOMIC_SEQ_CST operations.  It only says about other __ATOMIC_SEQ_CST operations; nothing is said about regular reads/writes.  This sounds quite far from our comment, promising full barrier semantics, which, in my understanding, means the equivalent of both pg_read_barrier()/pg_write_barrier(), which should barrier all other read/writes.This function first checks if LSE instructions are present.  If so, instruction LSE casal is used.  If not (in my case), the loop of ldaxr/stlxr is used instead.  The documentation says both ldaxr/stlxr provides one-way barriers.  Read/writes after ldaxr will be observed after, and read/writes before stlxr will be observed before.  So, a pair of these instructions provides a full memory barrier.  However, if we don't observe the expected value, only ldaxr gets executed.  So, an unsuccessful pg_atomic_compare_exchange_u64() attempt will leave us with a one-way barrier, and that caused a bug in my case.  In contrast, __sync_val_compare_and_swap() uses __aarch64_cas8_sync, which is quite the same as __aarch64_cas8_acq_rel, but has an explicit memory barrier in the end.