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

Paul Coccoli pcoccoli at gmail.com
Wed Jul 12 12:11:59 UTC 2006


On 7/11/06, Stefan Westerfeld <stefan at space.twc.de> wrote:
> 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 2.6.16.16 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.
>
>    Cu... Stefan
> --
> Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
>

What about POSIX real-time signals?  I know mixing threads and signals
is taboo, but I thought I'd throw it out there anyway.  Using pselect
then lets you wait atomically for events on file descriptors and/or
signals.  Not sure how well it works with threads, though...or if it's
even implemented (though it is described in select(2)).



More information about the Linux-audio-dev mailing list