26 Aug
2004
26 Aug
'04
6:10 a.m.
Tom Schouten wrote:
hi all,
i'm considering to add lock free queue support to packet forth, just to
follow the hype, and maybe also because i like the concept. but i'm
wondering if it would make much sense to go through all the trouble with
fast mutexes being available in 2.6
in other words, how much better (apart from being more elegant) are lock
free structures wrt a mutex approach where there is a minimal system
penalty? (not many collisions) did anyone look into this? or have i not
been lurking properly? ;)
OK, futexes are fast in the uncontested case so, with sufficiently rare
collisions,
you expect performance to approach that of a lock-free implementation.
And in terms of overall throughput, it probably does. But in terms of
worst case
delay when there *is* a collision things are no better. The point of the
lock-free
approach is to minimise this worst case delay in a real-time system, so
if this is
important to you then lock-free is the way to go (but see below).
I'm not sure if/when they'll become mainstream, but fuqueues might also be
worth a quick look. (Yes: It is an unfortunate name. Enough said.) They
tackle
the priority inversion problems that can occur with standard
m(/f)utexes, and
are intended for real-time use.
Simon Jenkins
(Bristol, UK)