Re: [boost] boost.lockfree update

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

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.

Thanks!