Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: EJ Campbell <email@hidden>
- Date: Fri, 01 Nov 2002 18:55:43 -0800
Thanks for the feedback! My reply is below.
On Friday, November 1, 2002, at 05:23 PM, David Leimbach wrote:
Interesting... more below.
On Friday, November 1, 2002, at 07:01 PM, EJ Campbell wrote:
I'm sorry for the cross-post. This is a followup to a question posted
on the Core Audio list, and I think it is appropriate for the darwin
list as well.
I'm trying to eliminate a priority inversion that occasionally occurs
while passing data between a single realtime thread and a single
worker thread. Data is passed using a lockless queue. After adding
each bit of data, the realtime thread signals the worker thread with
pthread_cond_signal(). Most of the time this works well. However,
occasionally the call to pthread_cond_signal() takes a long time
complete. It appears that pthread_cond_signal can indeed block.
A brief perusal of Darwin's source revealed that there's a private
lock associated with each condition variable. Both
pthread_cond_signal() and pthread_cond_wait() use this lock for
internal synchronization. So, if I'm reading it correctly, a thread
can block when calling pthread_cond_signal() if pthread_cond_wait()
is holding the lock at that time. I believe this would cause the
priority inversion that I'm seeing. Is my analysis correct?
If so, is there an alternative synchronization primitive that won't
block when signaling?
I have a tendency to use semaphores as a "signaling primitive" and a
work queue using a "producer/consumer" style design. Once the queue
is empty the consumer is asleep on the semaphore's value is zero the
producer can wake it up by posting to the semaphore. I don't know if
the post [which is like your cond-signal in some ways] blocks or not
but its an option.
This sounds promising. Which semaphore API are you using? The one
defined by POSIX (the sem_* variety) , the one from multiprocessing
services (MP*Semaphore), or some other API? The POSIX API looks most
promising since it seems to have been created with realtime usage in
mine. In fact, unlike the multiprocessing API, it explicitly mentions
how to avoid priority inversion.
One thing to note about pthread_cond_signal is if nothing is waiting
on the signal the signal is lost forever... they are not queued
anywhere. This is not a bug... its part of the design.
Yeah, I know about this. I get around it either by setting my timeout
low enough so that if a signal is missed, the worker thread will wake
before anything bad happens or if a little latency is acceptable, by
relying on the fact that the next item on posted on the queue will
signal the worker thread. However, using semaphores sounds like a
better idea since the worker thread will only be active when there are
items in the queue.
If not, is my only option to add polling to my worker thread and not
bother with the signaling at all?
Producer/consumer with work queues works for me.
This is encouraging. I'd hate to have to resort to polling, even if I
could get the timing accurate enough so that I minimized any busy
waiting.
Thanks again.
-EJ
_______________________________________________
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.