You correct, it is race condition safe like this. But that’s a great example of what I mean by “easy to break later”. A lot of code that looks semantically the same actually is not when it comes to atomic operation.
Also important to note, that this breaks by using a passing a different memory order flag (although the default parameter quarantees the sequential writes for freq and f) this behaviour could be (unknowingly) overwritten very easily.
Not really important for this frequency example, but might be for bigger more complex systems or data structures: you are not guaranteeing to call updateCoeff for every value being set exactly once and neither guarantee, you are calling it not multiple times for the same value, even though the parameter didn’t change.
It’s gotten a bit of topic (sorry about that!) but I outlined a few ready to use examples here: Threading - How to rebuild critical processing component from GUI input while processing is ongoing? - #12 by Rincewind
that JUCE (or someone else) wrote the hard part for. I think it’s in general a good advise, to try to built on battle tested synchronisation implemtations.