Repository navigation
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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.
existing arch-/generic- code and wire it up behind the option.
Nothing is removed; both build systems keep building both ways.
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.