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

[Lee Revell]

On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote:
> On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote:
> 
> > nice to hear that they are faster. on the other hand, once again POSIX
> > screws us all over by not integrating everything into a single blocking
> > wait call. i've said it before, i'll say it again - this is one of the
> > few things that the win32 API gets right - you can block in one call on
> > almost *anything*. AFAICT, you cannot select/poll on a msg queue.
> 
> You can build such a thing on top of condition variables - that
> is what they exists for - to let a thread wait one any condition
> you may want, no matter how complicated. 
> 

But, from the original post it seems that pthread_cond_signal is not
realtime safe as it locks a mutex:

__pthread_cond_signal (cond)
     pthread_cond_t *cond;
{
  /* Make sure we are alone.  */
  lll_mutex_lock (cond->__data.__lock);

  /* Are there any waiters to be woken?  */
  if (cond->__data.__total_seq > cond->__data.__wakeup_seq)
    {
      /* Yes.  Mark one of them as woken.  */
      ++cond->__data.__wakeup_seq;
      ++cond->__data.__futex;

      /* Wake one.  */
      lll_futex_wake (&cond->__data.__futex, 1);
    }

  /* We are done.  */
  lll_mutex_unlock (cond->__data.__lock);

  return 0;
}

How can glibc guarantee that we are not put to sleep if there is
contention?

Lee