Question about atomics

[Wiznat]

Just a quick question.

I recently watched one of the conferences about using std::atomic in the processBlock/Audio thread.

Should I always be using std::atomic when storing/loading and variables that will be accessed in the processBlock and outside of the processBlock function ? I wasn’t previously, so I’m guessing its not dire, but good practice.

A basic example being, I have a variable for the RMS level that I need to access from other threads at points. So this should be an std::atomic right?

And is storing/loading an atomic expensive? Especially considering its being done ~100 times a second?

Thanks.

[Fandusss]

Yes you should be using atomics. The issue you are avoiding is one thread might be writing new data to memory as another thread is reading it, so what ends up being read is some half/half value that results in undefined behaviour.

Apparently on some architectures floats behave like an atomic anyway, so that could be why you never had an issue with the RMS value. But it might be an issue on another system, so you should just avoid data races entirely.

[nicolasdanet]

HTH:

Std::atomic lock-freedom

Mintomic is a very small part in all the blog posts (anyway it is not used anymore). The C++11 atomics are largely covered. It is for me the best resource for beginners (easier at start that the Anthony Williams book for instance). My opinion is probably biased since i learned all (at first) with that blog! From oldest to newest: < Locks Aren't Slow; Lock Contention Is > < Always Use a Lightweight Mutex > < Roll Your Own Lightweight Mutex > < Implementing a Recursive Mutex > …

@Wiznat

And is storing/loading an atomic expensive?

You could use memory_order_relaxed to minimize the cost, but you need to fully understand it.

Std::atomic lock-freedom

Recently i read a paper about the OOTA/RFUB problem for memory_order_relaxed atomic variables. Nothing related directly to your question, but a clear warning about how concurrency can be a nightmare if you don’t stick to good practices and if you go in the UB world. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1217r0 YouTube / < A Relaxed Guide to memory_order_relaxed - Paul E. McKenney & Hans Boehm - CppCon 2020 - YouTube > < CppCon 2016: Hans Boehm “Using weakly ordered C++ atom…

If not, just use default std::atomic and think about optimization later.

[ImJimmi]

Should I always be using std::atomic when storing/loading and variables that will be accessed in the processBlock and outside of the processBlock function ? I wasn’t previously, so I’m guessing its not dire, but good practice.

You don’t need to use atomics for everything that’s used in and out of the process block, only things that are used on multiple threads.

Also, there’s some cases where it’s safe to use things on multiple threads without atomics or other thread safety. For example prepareToPlay, releaseResources, and numChannelsChanged (IIRC) will likely be called on the main thread, but the audio thread won’t be running at that point so it’s safe to use things that will also be used on the audio thread.

A basic example being, I have a variable for the RMS level that I need to access from other threads at points. So this should be an std::atomic right?

That sounds like a good use-case for an atomic, yeah!