Re: Trying out <stdatomic.h>

From: Greg Burd <greg(at)burd(dot)me>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Trying out <stdatomic.h>
Date: 2026-10-23 21:36:39
Message-ID: BGXViuPJAXY5dAefuF31MhArLzQjKYoS60rlNordOBLSX7_pATL66i-2-nYMIHeyoHSGLDQ3plkUjSpW-1SPAE4y0MBdWo8JVFbUj4UKKO4=@burd.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

As a companion to v11, here is v12: the same work as a single patch
that makes <stdatomic.h> the only atomics implementation, with no
build option. It is v11's 0001 and 0003 squashed together without the
benchmark harness; the atomics and spinlock code is byte-identical to
v11's opt-in stdatomic path.

I'm posting it because Peter asked where this is meant to end up, and
because a single patch is the easiest thing to evaluate if the answer
is "all the way". v11 is still the conservative route: an opt-in
alternative, default off, as Tom asked for. Which of the two to
pursue is a committer's call, and I'd rather offer both than guess.

What v12 removes: arch-arm.h, arch-ppc.h, arch-x86.h, fallback.h,
generic.h, generic-gcc.h, generic-msvc.h and storage/s_lock.h, plus the
s_lock_test program that exercised the old TAS macros (regress.c's
test_spinlock() still covers spinlocks). The public pg_atomic_* and
SpinLock* APIs are unchanged.

What it requires: a <stdatomic.h> whose 32- and 64-bit atomics are
always lock-free. configure and meson now fail with a clear message
otherwise, rather than falling back. That does not raise the MSVC
baseline: master already requires Visual Studio 2022 (6319d6372c8),
which provides <stdatomic.h> with /experimental:c11atomics.

Two things a committer should weigh before committing either version:

- pg_atomic_read_u32/u64 use memory_order_seq_cst, which is stronger
than their documented "no barrier semantics". With a relaxed read,
join_hash intermittently loses a tuple on rv64 built with gcc 13.3
(gcc 15.2 and clang 21 don't, and restoring the old spinlock doesn't
help). I haven't found the cause, so the stronger ordering stays
until someone does. It costs an LDAR on ARM64, two fences per load on
rv64 and an hwsync on POWER, across about 200 call sites, and I
haven't benchmarked that.
- I've tested on x86-64, aarch64 (macOS arm64 in CI), riscv64 and
Windows ARM64, but not on POWER, s390x or the Solaris/illumos
animals. The buildfarm would be the first real test there.

This is the last I'll post on the thread until there's more interest.
Thanks to Thomas for the original patches, and to Shihao for the
reviews.

best.

-greg

Attachment Content-Type Size
v12-0001-Use-C11-stdatomic.h-to-implement-port-atomics.h-.patch text/x-patch 129.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-10-23 21:47:54 Re: Let an ordering index scan hand its ORDER BY value to the target list
Previous Message Raja Sai pranav 2026-10-23 20:39:09 Incremental backup accepts a prior backup that extends past a timeline switch