11 Jul
2006
11 Jul
'06
9:43 p.m.
On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote:
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-
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.