Re: std::atomic and lock free algorithms with Core Audio
Re: std::atomic and lock free algorithms with Core Audio
- Subject: Re: std::atomic and lock free algorithms with Core Audio
- From: Ross Bencina <email@hidden>
- Date: Sun, 11 Sep 2016 17:08:02 +1000
On 11/09/2016 8:38 AM, Hovik Melikyan wrote:
Firstly, for atomic/aligned types such as Float32 or Int32 there has
to be a simple mechanism and I'm wondering, e.g. which of the
memory_order model should be used with these parameters.
The thing with parameters like volume and mute is that in principle it
is not required for changes to be immediately available for the audio
thread, but it should be "soon enough", say they should take effect
during the next rendering cycle. My first question is then, if I use
std::atomic<> (which I admit I still don't understand very well),
which memory ordering model to use? Is the relaxed model sufficient in
this case? On the other hand, is acquire/release semantics too
expensive for what I need?
If there is no ordering requirement between individual value updates and
other atomic/non-atomic code, then atomic relaxed is sufficient. The
other orderings are only useful when considering multiple related
reads/writes where their relative update order needs to be maintained.
Second, in more complicated cases like passing a block of parameters
to a parametric EQ, what is the best mechanism?
Not sure.
Another option I've found is a less known algorithm called "optimistic
reader" that involves a shared counter. The writer increments the
counter once when it starts writing and one more time when it ends.
The reader, in its turn, reads the counter, reads the data, then
compares the counter with the stored value. If the values don't match
it means the data block is likely inconsistent, and that it should
retry. While it sounds simple and elegant, there is at least one major
drawback that potentially the consumer may end up looping a lot. Also
for me there is a question again what memory ordering model to use
with the counter.
The reader can give up if it tries too many times (and if you think
about it, it's pretty unlikely that you'd need more than 2 retries). A
similar thing would apply to using a try-lock.
This is a good explanation of release/aquire:
http://preshing.com/20120913/acquire-and-release-semantics/
also
http://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/
There are many other excellent posts on Jeff Preshing's blog.
Ross.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden