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!