Hi @Mayae,
Thanks for your insights. Great post! I just learned a lot about atomics and memory ordering!
I am not arguing at all against std::atomics. That’s why I mentioned some examples of how things go wrong when you don’t use std::atomics. We also discussed yesterday in the JUCE team that we will be adding atomics to places in JUCE where necessary - also to AudioParameter. I’m also glad to get some clarification on performance of std::atomics in state-of-the-art compilers - last I checked compilers did create the sync instruction (even when optimisation was enabled) but that was a few years back.
I’m just also making the point that no-one needs to panic just yet when AudioParameter is not using atomics, as in practice, it’s very unlikely that things will go wrong (apart from the examples that I mentioned) and I’d even argue that it’s impossible when you are building an audio plug-in.
Let me clarify that last point again: an audio plug-in is a shared library and the compiler is technically unable to optimise beyond the entry points of the plug-in (how should it? - it doesn’t have access to the host program’s source code or binary). Therefore, any load/stores that have been optimised away or moved around will need to be inserted somewhere before any entry-point finishes. I know that the C++ standard does not mention this - so technically the world could explode, but I’m thinking of how all compilers currently work in practice.