Incorrect Statement about What is Impossible

[pl170491]

In the chapter about Atomics (Chapter 8.3 sub-section "Data Accesses") there is a very strong statement made about the possibility of synchronizing data between any two or more threads using only normal (i.e. non-atomic) data accesses. I believe there exists an algorithm for sharing data between two threads deterministically and correctly without the use of any atomic operations, and it works even on weakly ordered hardware (or at least so far I've tested it on Apple M3 which is ARM based, as well as the more strongly ordered Intel x86/64). As such, assuming I'm not utterly mistaken, I'd like to request that this statement be altered to better describe reality:

"It is literally impossible to write correct synchronized code using only data accesses."

The code is located here if you're interested in testing it to prove to yourself that what I say is true on your personal hardware.
https://github.com/alareti/fallout

[numberZero]

I think you are mistaken.

I believe there exists an algorithm for sharing data between two threads deterministically and correctly without the use of any atomic operations

There is none, by definition of a data race.

and it works even on weakly ordered hardware

Rust is not obliged to translate a ptr::read to a single mov or ldr or what the target CPU provides which makes hardware ordering and such rather irrelevant. In fact, if you have a ptr::read concurrent with a ptr::write to the same location Rust is not obliged to translate either to anything specific as that’s a data race and thus, outright UB.

On the other hand, with atomics the contract is different. Rust is still not obliged to translate accesses to any specific instructions but, it is very much obliged to make each atomic read work as if it was a single atomic read with the ordering as specified (which implicitly allows stronger ordering). Hardware properties don’t affect that either, they basically mean the compiler might be able to emit less barriers on x86 than on ARM to achieve the exact same result (up to no barriers and such for relaxed atomics, typically).

[scottmcm]

what I say is true on your personal hardware.

What happens today on hardware is largely irrelevant to what Rust's rules are.

If you're relying on the atomicness properties of the CPUs you're running on anyway, why can't you just use the appropriate atomic ordering that does that, and thus get the same instructions but without the data race UB? Especially if you're using std::sync::atomic::compiler_fence(SeqCst) anyway?