Re: multithreaded mixer
Re: multithreaded mixer
- Subject: Re: multithreaded mixer
- From: Jeff Moore <email@hidden>
- Date: Thu, 5 Feb 2004 12:14:40 -0800
On Feb 5, 2004, at 2:19 AM, Philippe Wicker wrote:
I think you misunderstood me here. I didn't mean that you need to take
a lock to signal the condvar. The lock on the signaler side is
necessary to avoid a race condition at the waiter side.
As you say, there is that possibility of a race. However, you can
structure your code to not have that race and to never have to take the
mutex guarding the predicate.
I don't use mach semaphores, so I can't comment on them. Also, there
is no reason why you have to use a signal to do this. You could just
as easily wake the thread up on the decrementer and thus save a bit
of overhead. After all, if it's good enough for the main IO thread,
it should be good enough for any auxiliaries, right?
I'm not aware of this technique. Is it documented somewhere? IOKit?
Available in user land?
This is how the various constructs that will wait for a signal with a
time out are implemented. In the HAL, the IO thread is woken up using
the call pthread_cond_timedwait_relative_np() but it would be true of
pthread_cond_timedwait() and the other constructs that have a
wait-with-timeout behavior too.
The advantage of using the timer is that it has a somewhat shorter path
for getting the waiting thread running again than using the untimed
wait and signal approach does provided the mutex involved is free.
Another advantage is the looser coupling between the threads involved
which adds flexibility in how things run. It's this flexibility that
allows the HAL to do what it does in the first place.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.