Boost logo

Boost :

Subject: Re: [boost] boost.lockfree update
From: Oleg Grunin (oleg00_at_[hidden])
Date: 2010-08-03 22:37:58

I am no expert in concurrent programming but I did try to use this
implementation of lockfree fifo in a real world app to see how it
compares with a few other alternatives: a serialized deque, intel's
concurrent_queue, a home grown implementation, and a couple of others.
Here's my 2c worth:

1. It seems to me that supporting only POD types makes this whole
exercise largely academic, since the things most people would want to
put in the queue will be _not_ be POD. And storing pointers may not be
an acceptable option either, since, presumably, if someone's looking for
a lock free queue his main concern is performance. I had to disable the
is_pod check just to be able to benchmark it. My understanding is that
fifo stores pointers to nodes which off from the heap. Is an
impossibility on all platforms to have a node with a non-pod type and
preserve the lock free semantics?

2. With VC++ on Windows both 32 and 64 bit, fifo reverts to using
spinlocks even though there's a 64 bit equivalent of interlocked
intrinsics in 64bit builds. Intel's implementation, I believe, supports
lockfree atomic<long long> even on 32 bit systems so this should be

3. I also think it's important to provide size() method if only for
monitoring purposes. (unsafe_size() maybe). Most people would want to
take some action if the size of the queue exceed a reasonable (in their
domain) limit.

4. is_lock_free() should be a compile time check. I may want to chose a
different queue if the lock free version isn't available.

All this said, I have to say that the fifo performance in our
environment (64 bit linux with 8 xeon processors, gcc 4.5) was quite
good. Comparable with tbb::concurrent_queue and way better than all the
other options we tried.


Boost list run by bdawes at, gregod at, cpdaniel at, john at