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

[Dave Robillard]

On Mon, 2006-06-05 at 01:21 +0200, Stefan Westerfeld wrote:
>    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.

I seem to be alone on this, but I still say semaphores are the best for
this - sem_post is async signal safe.  It might not be pedantically
"realtime safe" (depending what the Linux guys have done with futexes I
guess) but it's certainly far better than a mutex/cond pair (and I would
guess better than writing to a pipe as well).  A mutex obviously isn't
async signal safe, and I doubt writing to a pipe is either.

It's also handy that a semaphore is a counter, so you can easily
gracefully handle the case where the realtime thread is going a lot
faster than the consumer, or the consumer gets hung up for a little bit,
etc.

Semaphores seem about perfect for this to me.. am I missing something?
Why doesn't anyone ever recommend them?

-DR-