Re: MPNotifyQueue takes 500,000 nsec (worst case)
Re: MPNotifyQueue takes 500,000 nsec (worst case)
- Subject: Re: MPNotifyQueue takes 500,000 nsec (worst case)
- From: Kurt Revis <email@hidden>
- Date: Tue, 22 Oct 2002 13:08:48 -0700
Thanks for the very informative message! Always happy to learn more...
On Tuesday, October 22, 2002, at 11:09 AM, kelly jacklin wrote:
I suggest you use the pthreads APIs directly
(<http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h.html>).
They are relatively easy to use, closer to the metal (the MP API is
implemented atop pthreads APIs), and the pthread_cond_signal call does
not block. Although to be used properly, it must be used in
conjunction with a mutex lock, which can contend with the thread on
the "other side" of the condition, it is possible through a
combination of timed waits (effectively polite polling) to avoid
taking that lock, and still ensure proper operation.
How does pthread_cond_signal() manage not to block? It looks like it
calls semaphore_signal_thread() (in Mach) which is a kernel call--and I
thought all syscalls could possibly block the calling thread.
Do I have an over-simplified view of what's really happening?
(Probably!)
Compared to what I'm doing (having the consumer thread sleep for a
consistent amount of time when it runs out of data to process), it
looks like the approach you're suggesting would allow a smaller amount
of buffering between the ioproc and consumer, since the consumer will
be woken earlier by the pthread_cond_signal() than it otherwise would
have. I'll give it a try.
--
Kurt Revis
email@hidden
_______________________________________________
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.