[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