Code explanation for absence of stdatomic.h for python build

Python Help
22

None of these compile for C on NonStop.

23

What about the atomic intrinsics mentioned in the HPE docs?

For example:

#include <stdio.h>
#include <stdint.h>

int main(void) {
    int32_t x = 0;
    int32_t old = _atmAdd32(&x, 1);
    printf("_atmAdd32 %d %d\n", (int)old, (int)x);
    return 0;
}
24

Yes, this might compile, I have seen these declarations in a header file.

25

This compiled fine for NonStop. So you are suggesting to use these atomic intrinsics in place of atomics in pyatomic_std.h. Although I doubt there is full support. To begin with this can be done.

26

Yes, I’m suggesting you implement the pyatomic.h functions in terms of the available atomic intrinsics.

27

Thank you @colesbury , @Rosuav for your help, much appreciated.

28

I’d also suggest not writing special _acquire/_release/_relaxed functions. Those are optimisations so it’ll work fine if you fall back to the plain version.

29

Noted, Thanks.:+1:

30

I found a piece of code segment written for 16 bit atomic operation but type casting to 32 bit in pyatomic_std.h. atomic_load type case is of 32 bit, while obj is of 16 bit type.


static inline uint16_t
_Py_atomic_load_uint16(const uint16_t *obj)
{
    _Py_USING_STD;
    return atomic_load((const _Atomic(uint32_t)*)obj);
}

is this a mistake or was it deliberately added? I couldn’t find any other place where such a cast was done.

31

That definitely looks like a mistake to me.

32

Thanks for catching this. It will be fixed in gh-146227: Fix wrong type in _Py_atomic_load_uint16 in pyatomic_std.h by colesbury · Pull Request #146229 · python/cpython · GitHub