Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: Kurt Revis <email@hidden>
- Date: Mon, 4 Nov 2002 00:49:24 -0800
On Sunday, November 3, 2002, at 06:24 AM, kelly jacklin wrote:
Assuming that the semaphore_signal_thread call does not block, this
would be
the way to go. Furthermore, the semaphore APIs provide "sticky"
synchronization (like all semaphores), so this should provide the
opportunity to remove the timeout spinning entirely.
I can verify that using Mach semaphores appears to work pretty well. I
traced through the code for semaphore_signal() and I don't see any
obvious ways in which it can block for an extended period. (But I'm no
kernel hacker so YMMV.)
I've updated my sound-file-playing code to use this technique, in case
anyone is interested. Previously, its feeder thread was using usleep()
to periodically wake up and fill its buffer. Now it sleeps on
semaphore_wait(), and the audio IO thread calls semaphore_signal() when
appropriate. This is a little bit simpler than the old way.
http://www.snoize.com/Code/PlayBufferedSoundFile.tar.gz
As always, comments are appreciated, especially from folks with MP
machines (since I don't have one).
--
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.