Skip to content

Trying out <stdatomic.h> for port/atomics.h (opt-in alternative) [cf-7005] - #46

Draft
gburd wants to merge 6 commits into
masterfrom
stdatomic
Draft

gburd wants to merge 6 commits into
masterfrom
stdatomic

Conversation

@gburd

@gburd gburd commented Jul 13, 2026

Copy link
Copy Markdown
Owner

Purpose (gburd fork): exercise CI + OCR AI review on the stdatomic
series before pgsql-hackers. Targets the fork's master; opened draft.
cf-7005: https://commitfest.postgresql.org/patch/7005/


This series reimplements PostgreSQL's atomics (port/atomics.h) on top of
C11 <stdatomic.h>, picking up Thomas Munro's WIP and finishing it into a
reviewable, benchmarked form.

It is deliberately structured as an alternative, selectable
implementation -- not a replacement:

  • The build option (-Duse_stdatomic / --with-stdatomic) is a tri-state
    auto|yes|no and DEFAULTS TO "no". With the default, the traditional
    platform-specific atomics remain the implementation and are
    behavior-preserving; stdatomic is strictly opt-in.
  • Patches 1-5 are the proposal: they ADD the C11 path alongside the
    existing arch-/generic- code and wire it up behind the option.
    Nothing is removed; both build systems keep building both ways.
  • Patch 6 is marked "[NOT FOR MERGE... yet.]". It shows the eventual
    endgame -- deleting the traditional code once stdatomic has proven
    itself in the field -- purely so reviewers and the buildfarm can
    exercise the stdatomic-only end state. It is NOT being proposed for
    commit now, and the aggregate diffstat below includes its deletions.

So the answer to "is this making <stdatomic.h> mandatory?" is no:
through patch 5 the traditional path is intact, default, and selectable.

The one substantive semantics decision worth review is the memory
ordering of the generic read/write. Short version: the WRITE is relaxed
(plain STR, matching the documented "no barrier" contract), and the READ
is seq_cst -- which weak-memory correctness actually required (a C11
relaxed load is NOT equivalent to stock's volatile load; a parallel hash
join lost tuples on RISC-V with a relaxed read). Uncontended this costs
nothing measurable, and the earlier ~2% aarch64 regression (which was
the seq_cst STORE, now relaxed) is gone. Relaxing the read too and
giving just the hash-join consumer its ordering is documented follow-up.
Full data, per-op mapping, and methodology are in the accompanying
pgsql-hackers mail.

CI is green on all platforms (Linux 32/64 meson + autoconf, macOS,
Windows MSVC + MinGW, CompilerWarnings), Test world included.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant