3 ms·

Bruce Dawson recently put a bit of a different spin on things with his explanation: https://randomascii.wordpress.com/2020/11/29/arm-and-lock-free-programming/

Bruce Dawson recently put a bit of a different spin on things with his explanation: https://randomascii.wordpress.com/2020/11/29/arm-and-lock-free-programming/ https://randomascii.wordpress.com/2020/11/29/arm-and-lock-fr... > If you have circa-2005 code without these memory barriers then your code is broken, and has always been broken, on all CPUs, because compilers have always been allowed to rearrange writes. With these memory barriers (implemented as needed for different compilers and platforms) your code is beautiful and portable. > It turns out that ARM’s weak memory model really doesn’t make things any more complicated. If you are writing lock-free code and not using any sort of memory barriers then your code is potentially broken everywhere due to compiler reordering. If you are using memory barriers then it should be easy to extend them to include hardware memory barriers.

dragontamer 6y ago
The 00s were all about this multithreaded / multiCPU debate. For Java programmers, the solution was to establish memory-ordering at the language level (which then defined which optimizations a Java compiler was allowed, or not allowed to do). C++ programmers chose performance, though it wasn't until C++11 when the memory model was fully standardized. Indeed: ARM CPU-designers were still arguing for a weaker model than acquire/release: ARM CPU-designers wanted to implement consume/release semantics instead. (consume/release is "weaker": allowing for more reorderings and therefore more opportunities for higher-performance CPUs and/or code optimizations). Java's sequentially-consistent models are too strong (not enough optimizations available) for most programmers and most situations. Consume/release is in C++ standard, but few people understand it. Acquire/release is the model that seems to be winning out after all of these years. As a result, ARM and POWER are updating their CPUs to better-provide acquire/release semantics. (as the consume/release model of ARMv7 is simply not as popular).
- murderfs 6y ago
  A useful memory_order_consume is essentially unimplementable, to the point where the C++ standard itself says to not use it: https://eel.is/c++draft/atomics.order#1.3 https://eel.is/c++draft/atomics.order#1.3
MaxBarraclough 6y ago
> ARM’s weak memory model really doesn’t make things any more complicated. If you are writing lock-free code and not using any sort of memory barriers then your code is potentially broken everywhere due to compiler reordering. At the risk of mirroring dragontamer's comment, this figures. As that linked blog post explains, if you're programming in (modern) C++, you're writing for the standard C++ memory model, not the memory model of the target CPU architecture. Perhaps a weak memory model will make things interesting for the compiler team, but that's not your concern. Perhaps there could be performance consequences, but that's a different matter than writing broken code.

dragontamer 6y ago

The 00s were all about this multithreaded / multiCPU debate. For Java programmers, the solution was to establish memory-ordering at the language level (which then defined which optimizations a Java compiler was allowed, or not allowed to do). C++ programmers chose performance, though it wasn't until C++11 when the memory model was fully standardized. Indeed: ARM CPU-designers were still arguing for a weaker model than acquire/release: ARM CPU-designers wanted to implement consume/release semantics instead. (consume/release is "weaker": allowing for more reorderings and therefore more opportunities for higher-performance CPUs and/or code optimizations). Java's sequentially-consistent models are too strong (not enough optimizations available) for most programmers and most situations. Consume/release is in C++ standard, but few people understand it. Acquire/release is the model that seems to be winning out after all of these years. As a result, ARM and POWER are updating their CPUs to better-provide acquire/release semantics. (as the consume/release model of ARMv7 is simply not as popular).

murderfs 6y ago
A useful memory_order_consume is essentially unimplementable, to the point where the C++ standard itself says to not use it: https://eel.is/c++draft/atomics.order#1.3 https://eel.is/c++draft/atomics.order#1.3

MaxBarraclough 6y ago

> ARM’s weak memory model really doesn’t make things any more complicated. If you are writing lock-free code and not using any sort of memory barriers then your code is potentially broken everywhere due to compiler reordering. At the risk of mirroring dragontamer's comment, this figures. As that linked blog post explains, if you're programming in (modern) C++, you're writing for the standard C++ memory model, not the memory model of the target CPU architecture. Perhaps a weak memory model will make things interesting for the compiler team, but that's not your concern. Perhaps there could be performance consequences, but that's a different matter than writing broken code.