Re: best practices for sending data from UI to RemoteIO callback thread
Re: best practices for sending data from UI to RemoteIO callback thread
- Subject: Re: best practices for sending data from UI to RemoteIO callback thread
- From: Paul Davis <email@hidden>
- Date: Sat, 26 Mar 2011 17:57:03 -0400
On Sat, Mar 26, 2011 at 5:45 PM, Morgan Packard
<email@hidden> wrote:
> Great. Thanks. This had occurred to me as something that I should
> maybe be doing, but had been told that it probably wasn't necessary.
> Specifically, I'm triggering envelopes from my UI thread, which
> involves resetting the "current value" member variable of the
> envelope. I had been advised that a simple assignment of a float value
> wasn't likely to result in threading problems. But perhaps this isn't
> safe after all.
there are two separate issues.
1) atomicity of variable reads/writes
2) ordering
on most contemporary processors, reads/writes of 32 bit values are
atomic. that is, its not possible for any thread, on any CPU, to ever
catch the value "in the middle" of being updated. a reader will see
either the old value, or the new value, never something in between. i
don't know if this is true for floating point values on the processors
used in iOS devices.
ordering: you cannot control this without using write/read barriers,
not within a thread let alone between threads. if there are negative
side effects of one thread seeing an "out of order" value of a shared
variable, then you must use synchronization primitives or lock free
data structures.
however ... in audio work, there are a lot of cases that look roughly like this:
while (true) {
wait_to_be_woken_by_audioengine();
check_various_parameters ();
synthesize_and_process_data ();
}
if you miss a parameter change on one iteration of the loop, you'll
see it the next time around. so for quite a few things, its acceptable
to share a variable without using mutual exclusion or lock free data
structures. but you have to be very, very careful about this because
there are also a lot of things for which this will not work correctly
(even if it works most of the time).
_______________________________________________
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