I'm trying to substitute boost::lockfree::queue for std::queue in this websocket++ example https://github.com/zaphoyd/websocketpp/blob/experimental/examples/broadcast_server/broadcast_server.cpp
It looks like it can be done without really changing any syntax yet removing the boost::unique_lock lines.
However, when I look at the boost example, it has a code section that checks for lockfree http://boost-sandbox.sourceforge.net/doc/html/lockfree/examples.html
When I look through the docs on lockfree::queue, it says this on is_lock_free() http://boost-sandbox.sourceforge.net/doc/html/boost/lockfree/queue.html:
bool is_lock_free(void) const;
Warning
It only checks, if the queue head and tail nodes and the freelist can be modified in a lock-free manner. On most platforms, the whole implementation is lock-free, if this is true. Using c++0x-style atomics, there is no possibility to provide a completely accurate implementation, because one would need to test every internal node, which is impossible if further nodes will be allocated from the operating system.
Returns: true, if implementation is lock-free.
I have no idea what "c++0x-style atomics" are, but I'm pretty sure that c++0x mean c++11.
I'm using c++11 and merely substituting boost::lockfree::queue for std::queue, so will this not be implemented lockfree?
No. The "no possibility to provide a completely accurate implementation" comment refers to is_lock_free() - ie it is not guaranteed that is_lock_free() returns a result which accurately reflects whether the implementation is lock free. However, if is_lock_free() returns true, it's pretty likely that the implementation is lock free - but not absolutely, cast iron guaranteed.