# Is stdatomic.h optional or required? **URL:** \ **Category:** Core Development\ **Created:** [August 11, 2025, 9:25am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952 "2025-08-11T09:25:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [August 11, 2025, 9:25am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/1 "2025-08-11T09:25:32Z")
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](https://peps.python.org/pep-0007/#c-dialect) 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](https://discuss.python.org/t/code-explanation-for-absence-of-stdatomic-h-for-python-build/101623): > > 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 \ } # define \_Py\_USING\_STD using namespace std # define \_Atomic(tp) atomic\ #else # define \_Py\_USING\_STD # include \ #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? ---
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [August 11, 2025, 1:39pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/2 "2025-08-11T13:39:46Z")
Ooh I can answer this one, only because it was mentioned in [another thread](https://discuss.python.org/t/free-threading-expose-atomic-operations/101660/7) very recently. > [@Free-threading: expose atomic operations](https://discuss.python.org/t/free-threading-expose-atomic-operations/101660/7): > > 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 ``. > > Unfortunately, on Windows this needs `/experimental:c11atomics`. It’s been “experimental” for almost 3 years now. > Perhaps setuptools should add the flag automatically? ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [August 11, 2025, 1:50pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/3 "2025-08-11T13:50:18Z")
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. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [August 11, 2025, 1:50pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/4 "2025-08-11T13:50:44Z")
> [@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 \ but use GCC. I don’t know. ---
**Author:** ![ngoldbaum](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ngoldbaum/32/12276_2.png) [@ngoldbaum](https://discuss.python.org/u/ngoldbaum)\ **Post date:** [August 11, 2025, 8:01pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/5 "2025-08-11T20:01:03Z")
> [@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](https://github.com/python/cpython/commit/2bd960b57944107fbfbd8ff005b4223e1ea6555f) 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. ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [August 11, 2025, 8:17pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/6 "2025-08-11T20:17:54Z")
> [@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: > [@Code explanation for absence of stdatomic.h for python build](https://discuss.python.org/t/code-explanation-for-absence-of-stdatomic-h-for-python-build/101623/10): > > 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. ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [August 11, 2025, 9:06pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/7 "2025-08-11T21:06:33Z")
What does it do on thread-less platforms (like Webassembly)? ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [August 11, 2025, 9:10pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/8 "2025-08-11T21:10:12Z")
> [@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](https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=extension-atomic-operation-fetch-functions) ---
**Author:** ![ngoldbaum](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ngoldbaum/32/12276_2.png) [@ngoldbaum](https://discuss.python.org/u/ngoldbaum)\ **Post date:** [August 11, 2025, 9:17pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/9 "2025-08-11T21:17:09Z")
It looks like [this wasi buildbot build](https://buildbot.python.org/#/builders/1745/builds/489/steps/3/logs/stdio) finds stdatomic. Not sure about emscripten. ---
**Author:** ![mwichmann](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mwichmann/32/1364_2.png) [@mwichmann](https://discuss.python.org/u/mwichmann)\ **Post date:** [August 11, 2025, 9:31pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/10 "2025-08-11T21:31:37Z")
The header has this about right, can we just align other sources of information with this? ```c # error "no available pyatomic implementation for this platform/compiler" ``` ---
**Author:** ![ngoldbaum](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ngoldbaum/32/12276_2.png) [@ngoldbaum](https://discuss.python.org/u/ngoldbaum)\ **Post date:** [August 11, 2025, 11:22pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/11 "2025-08-11T23:22:21Z")
> [@da-woods](#): > > it looks like AIX may have an even older GCC extension FWIW, this link is broken (edit: now fixed) ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [August 12, 2025, 1:02am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/12 "2025-08-12T01:02:10Z")
> [@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.) ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [August 12, 2025, 11:36am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/13 "2025-08-12T11:36:37Z")
From [the 3.13 What’s New](https://docs.python.org/3/whatsnew/3.13.html#build-changes): > Building CPython now requires a compiler with support for the C11 atomic library, GCC built-in atomic functions, or MSVC interlocked intrinsics. I [noted](https://github.com/python/cpython/pull/108338#issuecomment-1690513914) that this needs a PEP 7 change, but [got overruled](https://github.com/python/cpython/pull/108338#issuecomment-1690533973). @colesbury, is it still possible to build CPython 3.13 with compilers that can build 3.11? ---
**Author:** ![colesbury](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/colesbury/32/28031_2.png) [@colesbury](https://discuss.python.org/u/colesbury)\ **Post date:** [August 12, 2025, 1:19pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/14 "2025-08-12T13:19:03Z")
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_atomic`and, if so, adjust the conditional guards. Otherwise, you need to provide your own compatible `pyatomic.h` ---
**Author:** ![colesbury](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/colesbury/32/28031_2.png) [@colesbury](https://discuss.python.org/u/colesbury)\ **Post date:** [August 12, 2025, 1:22pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/15 "2025-08-12T13:22:13Z")
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. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [August 12, 2025, 3:31pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/16 "2025-08-12T15:31:43Z")
So I guess PEP 7 should say: > - For Python 3.11 and newer versions, use C11 without [optional features](https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#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. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [August 22, 2025, 11:22am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/17 "2025-08-22T11:22:05Z")
A PR to update PEP 7: [PEP 7: Reword & split the "C dialect" section by encukou · Pull Request #4557 · python/peps · GitHub](https://github.com/python/peps/pull/4557) ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [August 22, 2025, 9:22pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/18 "2025-08-22T21:22:31Z")
> [@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. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [August 25, 2025, 3:12pm UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/19 "2025-08-25T15:12:27Z")
> [@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. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [August 27, 2025, 11:03am UTC](https://discuss.python.org/t/is-stdatomic-h-optional-or-required/101952/20 "2025-08-27T11:03:51Z")
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.