On Wed, Jun 07, 2006 at 05:42:26PM -0400, Lee Revell wrote: > But, from the original post it seems that pthread_cond_signal is not > realtime safe as it locks a mutex: > ... > How can glibc guarantee that we are not put to sleep if there is > contention?
The mutex associated with a CV is held only - by the sender while modifying the condition - by the receiver while checking the condition So it is not held by the receiver while it is descheduled and waiting. Suppose you use a CV from a JACK process callback to tell some other thread in your app that a period of new samples is now available in a circular buffer. There is a _very small_ chance that the mutex you need to take is held by the receiving thread - this will happen if JACK's thread pre-empted the receiver at exactly the moment it was checking the condition, i.e. in between its mutex_lock() and pthread_cond_wait (). In that case, if you used mutex_lock(), the receiver will take over for a very short time until it calls pthread_cond_wait(), and you will be able to continue after that. If that is not acceptable (i.e. if you have a *very* short period time), use mutex_try_lock() instead. If it fails, don't do the pthread_cond_signal() but remember you have to signal two periods next time. -- FA Follie! Follie! Delirio vano e' questo!