Is stdatomic.h optional or required?

[Rosuav (Chris Angelico)]

According to configure.ac, stdatomic.h is optional, with a notice being emitted if it is absent. (Side note: The message says “Your compiler or platform does have a working C11 stdatomic.h” which may be incorrect wording?) PEP 7 also states that C11 is required, without any optional features (stdatomic being an optional feature). However, a user attempting to compile on a non-standard platform is running into a problem with compiling, after having a successful configure (with the notice about there being no stdatomic).

Code explanation for absence of stdatomic.h for python build

Hi, Let’s say I am compiling Python-3.13.5 with a non GCC compiler. This leads to inclusion of pyatomic_std.h in the header file. pyatomic_std.h file has the following code, #ifdef __cplusplus extern "C++" { # include <atomic> } # define _Py_USING_STD using namespace std # define _Atomic(tp) atomic<tp> #else # define _Py_USING_STD # include <stdatomic.h> #endif ``` I am unable to understand the #ifdef __cplusplus part. CPython is compiled with c11 standards, and if stdatomic.h were no…

Currently, pyatomic.h is included unconditionally in Python.h, and pyatomic.h will load up one of the subheaders pyatomic_{gcc,std,msc}.h or error out. This suggests that some form of atomic support is mandatory, which isn’t mentioned in PEP 7.

Are there any supported platforms that do not have stdatomic.h?

[jamestwebber (James Webber)]

Ooh I can answer this one, only because it was mentioned in another thread very recently.

@encukou

Are load and store functions even the right API?
If you use _Atomic int for the variable, then normal loads and stores will be atomic. For more complex operations there are functions in <stdatomic.h>.

Unfortunately, on Windows this needs /experimental:c11atomics. It’s been “experimental” for almost 3 years now.
Perhaps setuptools should add the flag automatically?

[Rosuav (Chris Angelico)]

Thanks! My reading of that thread is that it’s probably going to be mandatory? I think? If that’s the case, then PEP 7 should be updated and the configure script changed to make that a hard requirement.

[vstinner (Victor Stinner)]

@Rosuav

Are there any supported platforms that do not have stdatomic.h?

Currently, the GCC implementation is used even if the C compiler is GCC, even if C11 atomics are supported. It seems like Include/cpython/pyatomic.h works on all platforms supported by PEP 11.

Maybe some platforms are missing <stdatomic.h> but use GCC. I don’t know.

[ngoldbaum (Nathan Goldbaum)]

@Rosuav

Currently, pyatomic.h is included unconditionally in Python.h, and pyatomic.h will load up one of the subheaders pyatomic_{gcc,std,msc}.h or error out. This suggests that some form of atomic support is mandatory, which isn’t mentioned in PEP 7.

Are there any supported platforms that do not have stdatomic.h?

CPython has required atomic support to build for a while now. It doesn’t require stdatomic support, and as explained elsewhere will fall back to platform-specific code, but will error out if it can’t find a platform-specific definition at build time.

This has been true since an early alpha of Python 3.13, or at least that’s when the compiler error was added to the exposed header: gh-108337: Add pyatomic.h header (#108701) · python/cpython@2bd960b · GitHub

I suspect the person in the other thread is using a somewhat nonstandard compiler setup that isn’t covered by CPython’s CI, and is somehow not hitting the LLVM or GCC-specific fallbacks in the pyatomic header. Some more info about what compiler toolchain they’re using would be helpful, I think, unless I missed that detail somewhere.

[Rosuav (Chris Angelico)]

@ngoldbaum

I suspect the person in the other thread is using a somewhat nonstandard compiler setup that isn’t covered by CPython’s CI, and is somehow not hitting the LLVM or GCC-specific fallbacks in the pyatomic header. Some more info about what compiler toolchain they’re using would be helpful, I think, unless I missed that detail somewhere.

The best info we have so far is:

@zuhu2195

Regarding your first question, my platform is NonStop(Non-Standard but similar to IBM AIX). Our compilers support C11 standards.

but “C11 standard” doesn’t mandate stdatomic, so it’s entirely possible that it’s not GCC and doesn’t have stdatomic.

I’ll ask, as I’m not sure the OP of that thread saw this thread.

@ngoldbaum

CPython has required atomic support to build for a while now. It doesn’t require stdatomic support, and as explained elsewhere will fall back to platform-specific code, but will error out if it can’t find a platform-specific definition at build time.

That sounds like the wording of the configure message should be adjusted, then; the build requires stdatomic now, as opposed to potentially requiring it in the future.

[da-woods]

What does it do on thread-less platforms (like Webassembly)?

[da-woods]

@Rosuav

That sounds like the wording of the configure message should be adjusted, then; the build requires stdatomic now, as opposed to potentially requiring it in the future.

I don’t think that’s quite right either. It sounds like it requires some implementation of atomics now. But that can be GCCs or MSVCs pre-standard implementation and not the C standard library one.

(Based on a quick search, it looks like AIX may have an even older GCC extension, although not the one that Python uses so they might be out of luck.) edit: fixed link IBM Documentation

[ngoldbaum (Nathan Goldbaum)]

It looks like this wasi buildbot build finds stdatomic. Not sure about emscripten.

[mwichmann (Mats Wichmann)]

The header has this about right, can we just align other sources of information with this?

#  error "no available pyatomic implementation for this platform/compiler"

[ngoldbaum (Nathan Goldbaum)]

@da-woods

it looks like AIX may have an even older GCC extension

FWIW, this link is broken (edit: now fixed)

[Rosuav (Chris Angelico)]

@mwichmann

The header has this about right, can we just align other sources of information with this?

That would be a policy decision, to be reflected in both PEP 7 and the configure script.

(EDIT: The alternative would be figuring out how to make Python build without atomics, and what those consequences are.)

[encukou (Petr Viktorin)]

From the 3.13 What’s New:

Building CPython now requires a compiler with support for the C11 atomic library, GCC built-in atomic functions, or MSVC interlocked intrinsics.

I noted that this needs a PEP 7 change, but got overruled.
@colesbury, is it still possible to build CPython 3.13 with compilers that can build 3.11?

[colesbury (Sam Gross)]

You need an implementation of pyatomic.h. Currently, that’s either stdatomic.h, __builtin_atomic, or Windows intrinsics. Most non-Windows compilers support some GCC extensions. You should check if the compiler supports GCC-style __builtin_atomicand, if so, adjust the conditional guards. Otherwise, you need to provide your own compatible pyatomic.h

[colesbury (Sam Gross)]

In 3.11, we required atomic support or we’d fallback to a broken non-atomic implementation. We could also do that, but I don’t think we should.

[encukou (Petr Viktorin)]

So I guess PEP 7 should say:

• For Python 3.11 and newer versions, use C11 without optional features. It’s OK to use optional features for which we have CPython-specific wrappers (notably, atomics).
• The public C API should be compatible with C99 and C++. We also have CPython-specific wrappers for several newer features; it’s OK to use those.

IMO, info on how to add new features is out of scope for a style guide.

[encukou (Petr Viktorin)]

A PR to update PEP 7: PEP 7: Reword & split the "C dialect" section by encukou · Pull Request #4557 · python/peps · GitHub

[da-woods]

@colesbury

In 3.11, we required atomic support or we’d fallback to a broken non-atomic implementation. We could also do that, but I don’t think we should.

There might be some value in being able to build a thread-less version of Python without atomics. That’d be better than broken thread-unsafe version, and would make it easy to get a minimal level of support on esoteric platforms.

It probably isn’t as simple to do that as I’m imagining though. And may not reach the “worth the effort” barrier.

[steve.dower]

@da-woods

There might be some value in being able to build a thread-less version of Python without atomics. That’d be better than broken thread-unsafe version, and would make it easy to get a minimal level of support on esoteric platforms.

There are plenty of applications where embedding a simpler CPython without threads would be beneficial. Anywhere that you have your own threading already and want to evaluate some Python code within it would make perfect sense. It’d probably take careful locking/scheduling on the part of the embedder, but if you’re doing anything halfway interesting (e.g. rendering video/3D) then you’ll already have it.

So I’d certainly be in favour of a build option to omit everything that assumes CPython is responsible for all its own synchronisation.

[encukou (Petr Viktorin)]

PEP 7 is now more obviously a style guide.

@steve.dower

Anywhere that you have your own threading already and want to evaluate some Python code within it

Sounds you’d want to replace, rather than omit, the threading parts?
pythreading.h does that for atomics; thread_*.h do that for threading itself. (I wouldn’t be surprised if this bit-rotted, but we can’t really prevent that without tests and active & involved users.)

As for platforms that are actually thread-less – we’ve left those to MicroPython, and CPython is better for it. A library can spin up a thread whenever it likes.