Current atomics are not defined to be lock-free

[brson]

Right now we define things like AtomicPtr unconditionally. On platforms without real atomics these get lowered to locks today. People write lock-free algorithms with these atomics that are not actually guaranteed to be lock free.

For comparison, I'm told (by @sunfish) that C++ does try to guarantee that atomics are lock-free.

cc rust-lang/rfcs#1543

[codyps]

C++ (and C11) makes no guarantee of it's atomics (in general) being lock-free. Only atomic_flag is guaranteed to be lock free. All other atomic<T> variants are allowed to be implemented by locks.

Previous discussion around this can be seen in rust-lang/rfcs#1505

[brson]

@jmesmon Ah, you are right. There is an api for asking whether atomics are lock free.

[Amanieu]

The plan with rust-lang/rfcs#1543 is to only expose atomic types which are guaranteed to be lock-free. Non-lock free atomic types can then be built on top of those, like I did in the atomic-rs library.

[dtolnay]

I believe this is being tracked in #32976, as it is the thing currently blocking stabilization of the atomic types from rust-lang/rfcs#1543.