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

   Hi!

I am trying to notify a high priority (nice -20 or nice -19) thread from
a realtime thread (from a jack callback to be precise). Of course I want
the realtime thread to not block, but I want the high priority thread to
react as soon as possible. For the first implementation, I used a
condition, and pthread_cond_signal. But as I can't aquire a mutex within
the realtime thread, at least not always (at most with trylock()), this
results in racy code.

Also, it doesn't integrate well with poll(), which the high priority
process should be able to use. So basically I want to switch to a pipe
write() instead of pthread_cond_signal.

Now the question is: am I producing priority inversion, then? I've seen
that the kernel code of pipe write has code like

        mutex_lock(PIPE_MUTEX(*inode));

(in fs/pipe.c, linux-2.6.16.16), so can this mutex cause priority
inversion?

However, on the other hand, I examined the code of
glibc-2.3.6/ntpl/sysdeps/pthread, and found in pthread_cond_signal.c:

__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;
}

So it looks like there is some kind of low level mutex locking involved
even when signalling a condition. Can't this also lead to priority
inversion?

So what is the best way to achieve that some lower priority thread will
definitely wakeup from a realtime priority thread, without causing
priority inversion, under recent linux kernels?

   Cu... Stefan

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan