Can pthread_cond_signal() block?
Can pthread_cond_signal() block?
- Subject: Can pthread_cond_signal() block?
- From: EJ Campbell <email@hidden>
- Date: Fri, 01 Nov 2002 17:01:37 -0800
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?
If not, is my only option to add polling to my worker thread and not
bother with the signaling at all?
Thank you very much!
Sincerely,
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.