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 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.
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. -DR-
