[linux-audio-dev] Multithreaded programming for a poll model?

Tim Goetze tim at quitte.de
Fri Jun 18 12:50:20 UTC 2004


[Paul Davis]

>>pipe()s here too. last time i benchmarked on an early 2.4 kernel, pipe
>>and socketpair gave about the same timing figures, quicker than
>>msgsnd/rcv. i don't remember the exact numbers but i remember being
>>positively surprised.
>
>from the whitepapers that IBM did, the linux FIFO appears to be just
>about the fastest IPC mechanism outside of a microkernel. i am not
>sure if even futexes are actually significantly faster.

do you happen to have a pointer ready to those IBM whitepapers you
mention?

i've dug up the old benchmarking code today. it starts a RT thread
that poll()s n times on a pipe, then pthread_cond_wait()s n times and
finally msgrcv()s n times. the main thread writes the current
gettimeofday() to a global and triggers the wakeup of the respective
waiting mechanism, which compares the current gettimeofday() upon
waking up. here are average numbers for 20 wakeups each:

poll: avg 0.01705 ms
cond: avg 0.01576 ms
msg : avg 0.01045 ms

this is on 2.4.22-ll, an 1.7 GHz athlon XP. the last time (referred to
above in the OP) was on 2.4.5-ll (iirc) and a k6-III-450. so either
they sped up msgsnd/rcv (which i doubt), my memory failed me (highly
probable :) or there are significant differences in the respective
kernel code path and processor flavour pairing (too esoteric to
check).

the conclusion i draw is that if you pthread_cond_wait now, you are
probably better off switching to msgsnd/rcv if it fits into your
scheme and you really want the speed. my personal opinion is that the
ease of use of pipe and poll outweighs the microsecond-order gain
msgsnd/rcv gives. it's still blazingly fast. ymmv of course.

i can upload the benchmarking code if there's interest.

>>giving you an fd, both pipe and socketpair can be operated on within a
>>poll() loop, which is quite handy sometimes. don't know if futexes
>>will do that?
>
>you can. it was added as an nth-round iteration of their
>design. otherwise, it would be just another example of the crappy *nix
>design where "waiting" is a different system call depending on what
>you're waiting for.

this sure is good news. though even if this weren't the case, i'm
quite comfortable with poll, and i'd rather work with 'crappy *nix
waiting' than ever MsgWaitForMultipleObjectsEx() another time in my
life :)

even if futexes will reach the speed msgsnd/rcv achieves, they'll have
to make them a real breeze to use to make me dump the working FIFO
code i am using now.

tim



More information about the Linux-audio-dev mailing list