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

Dave Robillard drobilla at connect.carleton.ca
Tue Jul 11 23:43:09 UTC 2006

On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote:
> > Semaphores seem about perfect for this to me.. am I missing something?
> Since we've been comparing different methods here, I thought I might as
> well write a benchmark, to look at the performance, too.  I wrote a
> little test which repeatedly switches between two threads, which wakeup
> eachother using a pipe, cond or semaphore.
> On an AMD64 3400+ (2200 MHz) running a kernel with preemption
> enabled, the timings for 1000000 iterations (each thread runs a brief
> period of time 1000000 times) are
>  - about 5.7 seconds when using a wakeup pipe and poll
>  - about 5.7 seconds when using a condition with mutex
>  - about 2.0 seconds when using a semaphore
> So: if what you're doing doesn't restrict you in any way, then
> semaphores are probably the thing to use.
> If you need to wait for multiple things simultaneously (like audio
> device fd and another thread), then you can do it with pipes and poll,
> but not with semaphores.

Nice.  I win! :)  I'd noticed a set of the pants improvement (increased
event processing throughput) when I switch to semaphores, but never ran
a real benchmark.

Good point on waiting for multiple things though, poll is a lot more
flexible than semaphores (though I still say writing to a pipe in a
realtime thread is pretty sketchy...).  Pipes let you communicate
between processes though - I havn't tried the fancier POSIX interprocess
stuff yet.


More information about the Linux-audio-dev mailing list