Trying out <stdatomic.h>

On 10/11/2025 15:17, Thomas Munro wrote:

Hi,

Here is an experimental patch to try out standard C (and C++) atomics
to implement port/atomics.h, and also add more types and operations.
It's mostly just redirecting our names to the standard ones, except
for our barriers and slightly extended pg_atomic_flag, so there isn't
much left of the code.

9 files changed, 166 insertions(+), 1824 deletions(-)
...
8 files changed, 176 insertions(+), 881 deletions(-)
...
7 files changed, 1 insertion(+), 394 deletions(-)

Nice!

[PATCH v1 1/4] Add some missing #include <limits.h>.

This seems like a good thing regardless of the other patches.

The "#include <limits.h>" lines in src/backend/lib/dshash.c and
src/backend/storage/lmgr/condition_variable.c are slightly misplaced:
system headers should be included between "postgres.h" and other
postgres headers.

Here also is a semi-independent patch to implement storage/spin.h with
pg_atomic_flag. It keeps a small amount of the architecture-specific
magic, but moves it out to src/port/spin_delay.h.

Makes sense.

The patch removes 'src/template/solaris'. Is that on purpose? Is that an
independent cleanup that could be committed immediately?

- Heikki

Heikki Linnakangas <hlinnaka@iki.fi> writes:

The patch removes 'src/template/solaris'. Is that on purpose? Is that an
independent cleanup that could be committed immediately?

Our four Solaris+illumos buildfarm animals would be sad.

regards, tom lane

On Tue, Nov 11, 2025 at 4:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Heikki Linnakangas <hlinnaka@iki.fi> writes:

The patch removes 'src/template/solaris'. Is that on purpose? Is that an
independent cleanup that could be committed immediately?

Our four Solaris+illumos buildfarm animals would be sad.

Looks like I overdid it while rebasing over the commit that removed
the dead Sun compiler... will put that bit back.

On Tue, Nov 11, 2025 at 2:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

[PATCH v1 1/4] Add some missing #include <limits.h>.

This seems like a good thing regardless of the other patches.

Pushed.

The patch removes 'src/template/solaris'. Is that on purpose?

Fixed.

It passes with VS 2022 on CI. I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet. They are definitely lock-free though[1]https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual-studio-2022-version-17-5-preview-2/, and the macros are
defined for C++, and the same under the covers... Perhaps
feature/conformance macros won't be defined until a few remaining
pieces (things we don't care about) are accessible from C? (I see
that Visual Studio 2026 has also just shipped a couple of days ago,
not investigated.)

[1]: https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual-studio-2022-version-17-5-preview-2/

On 13.11.25 12:35, Thomas Munro wrote:

It passes with VS 2022 on CI. I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet. They are definitely lock-free though[1], and the macros are
defined for C++, and the same under the covers... Perhaps
feature/conformance macros won't be defined until a few remaining
pieces (things we don't care about) are accessible from C? (I see
that Visual Studio 2026 has also just shipped a couple of days ago,
not investigated.)

Note also that we still have buildfarm members with gcc <4.9, which is
required for stdatomic.h/_Atomic there.

We could most likely resolve to get rid of them when the time comes, but
let's not forget to plan that.

Hi Thomas,

It passes with VS 2022 on CI. I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet. They are definitely lock-free though[1], and the macros are
defined for C++, and the same under the covers... Perhaps
feature/conformance macros won't be defined until a few remaining
pieces (things we don't care about) are accessible from C? (I see
that Visual Studio 2026 has also just shipped a couple of days ago,
not investigated.)

Thanks for working on this. I checked v2 on Linux x64 with and without
Valgrind and it passed all the tests. I haven't looked at the code
closely yet.

--
Best regards,
Aleksander Alekseev

On Thu, Nov 20, 2025 at 12:23 AM Peter Eisentraut <peter@eisentraut.org> wrote:

On 13.11.25 12:35, Thomas Munro wrote:

It passes with VS 2022 on CI. I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet. They are definitely lock-free though[1], and the macros are
defined for C++, and the same under the covers... Perhaps
feature/conformance macros won't be defined until a few remaining
pieces (things we don't care about) are accessible from C? (I see
that Visual Studio 2026 has also just shipped a couple of days ago,
not investigated.)

Note also that we still have buildfarm members with gcc <4.9, which is
required for stdatomic.h/_Atomic there.

Those are EOL'd RHEL/Centos 7 and SUSE 12 systems. A decision to
require GCC 4.9+ might not be fatal to them though, as those distros
had optional newer tool chain packages too. I'm not sure what
problems could follow from that, probably not much as far as C goes?
C++ ABI questions are always harder but such old systems couldn't
possibly use LLVM as we chop old releases based on distro EOL dates,
and LLVM adopts new language standards (being a compiler project after
all). (It'll be interesting to see what happens when LLVM requires
C++23, and then RHEL's new rolling LLVM upgrade policy meets its 10
year old stable compiler policy...)

The elephant in the room is Visual Studio. We have drongo on 2019,
hammerkop on 2022, and CI on 2019 but ready to flip to 2022 whenever
we're ready. There is no testing for 2026, being only a few days old
(I heard from Bilal that our CI passed when he tried it out FWIW).
2019 fell out of "mainstream" support 1.6 years ago[1]https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019, "extended"
support lasts 3.4 more years, and 2017's "extended" support also lasts
1.4 more years, which didn't stop commit 8fd9bb1d from chopping it to
gain some C11 support. When could we chop 2019 too, to gain more C11
support?

What motivation do people have to use old compilers for new software?
If my google-search-fu is serving me, upgrades are either free
(community edition for individuals, also for organisations working on
open source) or included in various paid subscriptions. Is there a
technical reason to be more conservative, for example, in terms of
library versions on the target system, something to do with UCRT or
_WIN32_WINNT versions that the EDB installer needs to target before
you can use this stuff? I can't find anything saying so. Perhaps
it'd be better to wait until /experimental:c11atomics isn't needed
though. My impression so far is that that's about conformance with
details we don't care about, not the maturity of the codegen which is
used far and wide in C++, it's just that C conformance is a distant
second priority (1½ decades later), but... (Not that this project is
finished anyway, more study and validation required.)

[1]: https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019

On Thu, Nov 20, 2025 at 3:03 AM Aleksander Alekseev
<aleksander@tigerdata.com> wrote:

Thanks for working on this. I checked v2 on Linux x64 with and without
Valgrind and it passed all the tests. I haven't looked at the code
closely yet.

Thanks for testing!

The next thing on my TODO list for this is some kind of codegen diff
on a full matrix of targets.

On Mon, Nov 10, 2025, at 10:19 AM, Tom Lane wrote:

Heikki Linnakangas <hlinnaka@iki.fi> writes:

The patch removes 'src/template/solaris'. Is that on purpose? Is that an
independent cleanup that could be committed immediately?

Our four Solaris+illumos buildfarm animals would be sad.

regards, tom lane

I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside. As an old Sun engineer I hate to see it disappear, but it is basically EOL at this point.

-greg

On Mon, Nov 10, 2025, at 8:17 AM, Thomas Munro wrote:

Hi,

Here is an experimental patch to try out standard C (and C++) atomics
to implement port/atomics.h, and also add more types and operations.
It's mostly just redirecting our names to the standard ones, except
for our barriers and slightly extended pg_atomic_flag, so there isn't
much left of the code.

Here also is a semi-independent patch to implement storage/spin.h with
pg_atomic_flag. It keeps a small amount of the architecture-specific
magic, but moves it out to src/port/spin_delay.h.

I'm not saying they're correct, performant or portable yet, that'll
require studying codegen and performance on a bunch of weird and
wonderful systems, but they at least passes basic testing on the usual
suspects and CI systems, except for Windows which needs a newer
toolchain so I haven't tried yet. It should hopefully just work™ on
VS 2022 (same version that provides <threads.h>, about which more
soon).

All that being the case, it's not far enough along to be a serious
proposal, but I imagine others will be looking into things like this
since we pulled the trigger on C11 and I figured I might as well share
a basic working patch set to avoid duplicated effort... Hopefully it
works well enough to kick the tyres and try to find the difficult
problems, test it out on weird systems, etc etc.

Attachments:
* v1-0001-Add-some-missing-include-limits.h.patch
* v1-0002-Redefine-port-atomics.h-on-top-of-stdatomic.h.patch
* v1-0003-Use-atomics-API-to-implement-spinlocks.patch
* v1-0004-Remove-configure-meson-checks-for-atomics.patch

Hello Thomas,

First off, thanks for working on this set of changes. I like your changes in general, except for removing Solaris/Illumos (but I get it). ;-P

As mentioned on a separate thread about fixing ARM64 support when building with MSVC on Win11 [1]/messages/by-id/3c576ad7-d2da-4137-b791-5821da7cc370@app.fastmail.com I tried out this patch. The reply on that thread had an issue with _mm_pause() in spin_delay(), it turns out we need to use __yield() [2]https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-180. I went ahead and fixed that, so ignore that patch on the other thread [1]/messages/by-id/3c576ad7-d2da-4137-b791-5821da7cc370@app.fastmail.com. The new patch attached that layers on top of your work and supports that platform, there was one minor change that was required:

#ifdef _MSC_VER

/*
* If using Visual C++ on Win64, inline assembly is unavailable. Use a
* _mm_pause intrinsic instead of rep nop. For ARM64, use the __yield()
* intrinsic which emits the YIELD instruction as a hint to the processor.
*/
#if defined(_M_ARM64)
__yield();
#elif defined(_WIN64)
_mm_pause();
#else
/* See comment for gcc code. Same code, MASM syntax */
__asm rep nop;
#endif
#endif /* _MSC_VER */

Visual Studio 2026 (Community)
cl (msvc 19.50.35718 "Microsoft (R) C/C++ Optimizing Compiler Version 19.50.35718 for ARM64")
link 14.50.35718.0

tests are passing, best.

-greg

[1]: /messages/by-id/3c576ad7-d2da-4137-b791-5821da7cc370@app.fastmail.com
[2]: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-180

"Greg Burd" <greg@burd.me> writes:

I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside. As an old Sun engineer I hate to see it disappear, but it is basically EOL at this point.

I think we can keep it going as long as there are people interested
in it. The gating factor at present is probably whether it can
provide an adequate C11 environment. But so far I've observed no
issues with the existing BF members.

regards, tom lane

On 2025-Nov-23, Tom Lane wrote:

"Greg Burd" <greg@burd.me> writes:

I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside. As an old Sun engineer I hate to see it disappear, but it is basically EOL at this point.

I think we can keep it going as long as there are people interested
in it. The gating factor at present is probably whether it can
provide an adequate C11 environment. But so far I've observed no
issues with the existing BF members.

Right -- we have

billbug Solaris 11.4.81 CBE 04.2025 gcc 14.2.0
hake OpenIndiana / Illumos gcc 9.3.0
margay Solaris 11.4.42 CBE gcc 11.2.0
pollock OmniOS / illumos gcc 10.2.0

Hake actually says:
gcc (OpenIndiana 13.3.0-oi-2) 13.3.0

and pollock:
gcc (OmniOS 151054/14.2.0-il-1) 14.2.0

so it looks like the oldest is Margay's 11.2, which claims [1]https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Standards.html#C-Language to
support C11, though there are some bugs that were claimed fixed in later
releases of GCC 11.x related to alignment[2]https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=FIXED&amp;target_milestone=11.3 and further for 11.4, 11.5, 11.6.. Perhaps relevant, but I
only searched the strings "align" and "c11" there, they may not apply to
our usage. At least the owner of margay and billbug is active, so we
can probably get the compiler in these machines updated if needed.

[1]: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Standards.html#C-Language
[2]: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=FIXED&amp;target_milestone=11.3 and further for 11.4, 11.5, 11.6.
and further for 11.4, 11.5, 11.6.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

On Mon, Nov 24, 2025 at 6:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Greg Burd" <greg@burd.me> writes:

I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside. As an old Sun engineer I hate to see it disappear, but it is basically EOL at this point.

I think we can keep it going as long as there are people interested
in it. The gating factor at present is probably whether it can
provide an adequate C11 environment. But so far I've observed no
issues with the existing BF members.

Yeah, Solaris has caused comparatively little trouble, if you exclude
the defunct compiler and a build farm animal running a frozen zombie
Solaris version. It's pretty easy for Linux users to understand
because of its huge influence on standards and conventions back in the
90s. The buildfarm animals are maintained by people with a real
interest in PostgreSQL on both OSes, and both OSes fix bugs we report
and track POSIX actively. We've run on SunOS/BSD and descendents for
coming up 40 (POSTGRES) or 30 (PostgreSQL) years, and I'm hoping we'll
even get to complete that Berkeley to-do item about using threads on
SunOS one of these days... I just goofed when rebasing the v1 patch
and git rm-ed the template file instead of git add-ing it in v1, but I
fixed that in v2.

On Mon, Nov 24, 2025 at 4:23 AM Greg Burd <greg@burd.me> wrote:

As mentioned on a separate thread about fixing ARM64 support when building with MSVC on Win11 [1] I tried out this patch. The reply on that thread had an issue with _mm_pause() in spin_delay(), it turns out we need to use __yield() [2]. I went ahead and fixed that, so ignore that patch on the other thread [1]. The new patch attached that layers on top of your work and supports that platform, there was one minor change that was required:

#ifdef _MSC_VER

/*
* If using Visual C++ on Win64, inline assembly is unavailable. Use a
* _mm_pause intrinsic instead of rep nop. For ARM64, use the __yield()
* intrinsic which emits the YIELD instruction as a hint to the processor.
*/
#if defined(_M_ARM64)
__yield();
#elif defined(_WIN64)
_mm_pause();
#else
/* See comment for gcc code. Same code, MASM syntax */
__asm rep nop;
#endif
#endif /* _MSC_VER */

That makes more intuitive sense... but I didn't know that people *do*
sometimes prefer instruction synchronisation barriers for spinlock
delays:

https://stackoverflow.com/questions/70810121/why-does-hintspin-loop-use-isb-on-aarch64

When reading your patch I was pretty confused by that, because it said
it was fixing a barrier problem and apparently doing so in an
unprincipled place. I guess we really need to research the best delay
mechanism for our needs on this architecture, independently of the
compiler being used, and then write matching GCC and Visual Studio
versions of that? I think there were some threads about spinlock
performance on Linux + Graviton with graphs and theories...

tests are passing, best.

Great news! Thanks. It sounds like if I could supply the missing
credible evidence of codegen quality on... all the computers, then I
think we'd be down to just: when can we pull the trigger and require
Visual Studio 2022 and do we trust /experimental:c11atomics?

FTR I had earlier shared some version of this patch with Dave when he
was trying to get his Windows/ARM system going, but I think my earlier
version was probably too broken. Sorry Dave. At that stage I was
also trying to do it as an option but keeping the existing stuff
around. Since then we adopted C11, so this is the all-in version. I
also hadn't understood a key part of the C11 memory model that your
RISC-V animal taught me and that c5d34f4a fixed, and you can see in
this patch set too, and I'm not sure if Visual Studio is like GCC or
Clang in that respect. It crossed my mind that this might even be
related to the problem you've noticed with barriers being missing, but
I haven't looked into that. BTW I believe we could actually change
our code NOT to rely on that, ie to follow the C11 memory model better
and declare eg PgAioHandle::status as atomic_uint8 or whatever (other
non-atomic access would be considered dependent and do the right thing
IIUC), but I'm not sure if it's necessary and that research project
can wait.

On Nov 23 2025, at 4:08 pm, Thomas Munro <thomas.munro@gmail.com> wrote:

On Mon, Nov 24, 2025 at 4:23 AM Greg Burd <greg@burd.me> wrote:

As mentioned on a separate thread about fixing ARM64 support when
building with MSVC on Win11 [1] I tried out this patch. The reply on
that thread had an issue with _mm_pause() in spin_delay(), it turns
out we need to use __yield() [2]. I went ahead and fixed that, so
ignore that patch on the other thread [1]. The new patch attached
that layers on top of your work and supports that platform, there was
one minor change that was required:

#ifdef _MSC_VER

/*
* If using Visual C++ on Win64, inline assembly is
unavailable. Use a
* _mm_pause intrinsic instead of rep nop. For ARM64, use the __yield()
* intrinsic which emits the YIELD instruction as a hint to
the processor.
*/
#if defined(_M_ARM64)
__yield();
#elif defined(_WIN64)
_mm_pause();
#else
/* See comment for gcc code. Same code, MASM syntax */
__asm rep nop;
#endif
#endif /* _MSC_VER */

That makes more intuitive sense... but I didn't know that people *do*
sometimes prefer instruction synchronisation barriers for spinlock
delays:

https://stackoverflow.com/questions/70810121/why-does-hintspin-loop-use-isb-on-aarch64

When reading your patch I was pretty confused by that, because it said
it was fixing a barrier problem and apparently doing so in an
unprincipled place. I guess we really need to research the best delay
mechanism for our needs on this architecture, independently of the
compiler being used, and then write matching GCC and Visual Studio
versions of that? I think there were some threads about spinlock
performance on Linux + Graviton with graphs and theories...

Interesting, I think I was rushing to get past that compile issue rather
than optimizing. This sounds like yet another place where we should
choose based on arch and it seems hint::spin_loop() does.

tests are passing, best.

Great news! Thanks. It sounds like if I could supply the missing
credible evidence of codegen quality on... all the computers, then I
think we'd be down to just: when can we pull the trigger and require
Visual Studio 2022 and do we trust /experimental:c11atomics?

I'm in favor of the stdatomic approach. I can't speak to codegen
quality on *all the platforms* or how *experimental* c11 atomics are
when using MSVC.

FTR I had earlier shared some version of this patch with Dave when he
was trying to get his Windows/ARM system going, but I think my earlier
version was probably too broken. Sorry Dave. At that stage I was
also trying to do it as an option but keeping the existing stuff
around. Since then we adopted C11, so this is the all-in version. I
also hadn't understood a key part of the C11 memory model that your
RISC-V animal taught me and that c5d34f4a fixed, and you can see in
this patch set too, and I'm not sure if Visual Studio is like GCC or
Clang in that respect.

Thanks for that work on RISC-V, I appreciate that! Much more digging to
be done to answer those questions for sure.

It crossed my mind that this might even be
related to the problem you've noticed with barriers being missing, but
I haven't looked into that. BTW I believe we could actually change
our code NOT to rely on that, ie to follow the C11 memory model better
and declare eg PgAioHandle::status as atomic_uint8 or whatever (other
non-atomic access would be considered dependent and do the right thing
IIUC), but I'm not sure if it's necessary and that research project
can wait.

Interesting. Yeah, let's do one thing and then move to the next, but I
do like the idea.

best.

-greg