hi daniel, thanks for your review!
*What is your evaluation of the implementation?* In my testing I ultimately removed boost::lockfree::fifo's from my code because they were the performance bottleneck. Don't use lock free fifo's for short lived 'wait queues' such as a shared future<> object or any application that may have 'surges' of demand that allocate large amounts of memory that will never be freed until the fifo is destroyed.
i've never argued that boost.lockfree has a high performance (as in throughput), but my main concern is lock-freedom. in many cases, lock-based data structures can outperform lock-free ones (because atomic operations are usually pretty expensive). but in some use cases (e.g. in real-time systems) one wants to use data structures that are slow but are guaranteed to be lock-free. as for the problem of memory reclamation: this is not a trivial issue and unfortunately the published algorithms (hazard pointers and pass-the-buck) are patented.
Several use-cases were ignored which have much more efficient lock free implementations than the general case. - multiple producer, single consumer. - single producer, single consumer - multiple producer, multiple pop-all - unordered producer-consumer queues
it actually contains a spsc queue (originally named `ringbuffer', but i am planing to rename it to `spsc_queue').
Ultimately I used an intrusive fifo where the elements (tasks) contained pointers to the next task (if any). I then atomically updated the head pointer to insert new nodes. To pop nodes I atomically swap the head node to NULL then process all the nodes in the list from tail to head to maintain fifo order.
i'd be curious to see the code for this, is it available?
Despite the problems I had with it, I see no reason not to accept it as a good start toward what I hope will be come a larger collection of lock-free containers.
i'd be happy to see contributions to the library ;) cheers, tim