[linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write

[Fons Adriaensen]

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!