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 11:36:59 -0700
On May 6, 2009, at 10:32 AM, William Stewart wrote:
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.
umm - I think I misread Ethan's comment. so, sorry about that.
Hopefully though the explanation below will help to describe why you
can't allow the render thread to go into an unbounded wait state
Bill
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
_______________________________________________
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