As explained in the first post, the underlying cpu instructions for various atomic operations are not guaranteeable by the wheel spec or by limiting support to the platforms python itself supports. As wheels distribute compiled code, this leaves various options, none of which are satisfying.
- Don’t use atomics
- Only use a slow, internally locking version of atomic values.
- Don’t distribute wheels.
- Ship a fat runtime and do runtime dispatching.
- Don’t provide this for other people at all.
Exposing the header does not solve this, there would need to be something provided by the c-api that abstracts it via interaction with the interpreter per-platform, or packaging needs to evolve to be able to package not just by platform, but by available instruction sets.
As for whether or not this should be included in the standard library, I don’t think a RWLock is exactly new or novel. It’s just not been something most people are going to have needed with the available parallelism previously available in python. It’s usually the best lock option for concurrency that requires explicit synchronization, and I don’t have high expectations on all existing python code being rewritten to be lock-free concurrency safe.
I don’t think atomic values are exactly new or novel either, but it’s arguable that providing the things people would build with them is sufficient.