Re: Locking mutex in render callback....
Re: Locking mutex in render callback....
- Subject: Re: Locking mutex in render callback....
- From: William Stewart <email@hidden>
- Date: Wed, 6 May 2009 10:32:20 -0700
On May 6, 2009, at 6:40 AM, Ethan Funk wrote:
Actually, the render could be forced to wait... If the render is
being executed at the same time that the source is executing: either
on a different processor core, or by chance the source thread is
preempted in the middle of the code where it locks the multex.
No, it can't.
The render thread is on a deadline, which is determined by your chosen
I/O cycle size. It has to complete its work by that deadline, or you
will have a break up in the audio.
The problem is more correctly characterised as "not allowing unbounded
waiting", rather than locking per sé
In the public utility code there is a class call CAMutex (and
CAGuard), it has a Wait and a Try method. The Wait method will wait
for an unbounded time on a lock if the lock is contested, and it
returns when it has acquired the lock.
The Try method will attempt to take the lock. If the lock is already
owned by another thread, then Try will return, having failed to take
the lock.
A typical pattern of usage then is:
Call on the render thread:
Do a Try - if it fails, then you do whatever that means (some other
thread has the lock). If it succeeds, then the render thread has the
lock and you can do whatever that means
On any other thread
Do a Wait - normally, you just want the lock here. You can of course
also limit your Wait to some timeout, or other techniques to finesse
the unbounded wait condition if that is a potential problem.
The CAGuard/Mutex classes are just wrappers around pthread primitives,
but we've found them useful. The Tryer and Lock classes are great for
managing stack based aquisition and release of the locks.
All your flags appear to be 4 byte of smaller integers. Reading and
writing to such variables is atomic, so you can just do away with
the mutex altogether if you can tolerate a situation where some
flags have been updated and not thers.
It is generally preferable to not use locks, so as Ethan suggests, the
use of atomic operations can be quite handy. in the public utility
code we have wrappers around these as well, including some atomically
managed stacks/queues and ring buffers, which might be useful.
Bill
_______________________________________________
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