is boost::lockfree::queue not lockfree with c++11?

Question

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?

Til

I urge you to measure before committing to lock-free algorithms -- they're neat but designed to be scalable and safe (ie. prevent priority inversion) -- performance is of less concern and typically worse. For instance, Boost's lock-free queue implementation will be slower than a locked std::queue unless you've got several cores and a very high amount of contention. – Lehrer

I have no idea what "c++0x-style atomics" are is talking about boost::atomic which the library relies upon. – Clearance

+1 for the lib example – Eponymy

Answer 1

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.

Mckinnon

Thank-you! Would you say it's safe to use with the example above, or should I expect lost messages/connections on a regular basis? – Til

Why would you expect something to get lost? – Lehrer

@CoryNelson Because I'm completely c++ inexperienced. is_lock_free makes it sound like there might be situations where it's not lock free, so something "bad" might happen like lost messages/connections. – Til

I think you probably want to read about what a lock-free algorithm is. – Mckinnon

if is_lock_free is false, that only means that it will use locks internally. The algorithm will still be thread-safe, just without the extra properties people use lock-free algorithms for. – Lehrer

@CoryNelson Please expand to answer for + n chk. – Til

Honestly, that's a very different question (basically, "what is a lock-free algorithm") as opposed to your original question, which is about whether a specific algorithm in a specific library is lock-free. – Mckinnon

@PhilipKendall Can you update your answer to include Cory's info? While you definitely added important knowledge (and my upvote stands; I don't understand who just dvoted u), Cory better understood the original intent relative to my hyper ignorance. lol – Til

I don't honestly think that would be useful to other readers of the site - people aren't going to look at a specific question on boost::lockfree::queue for general information on what a lock-free algorithm is. If you think that kind of information would be useful to other readers of the site, can I suggest you ask a different question instead? (although think carefully about which SE site it should be on and whether it's been asked before). – Mckinnon

Answer 2

I have no idea what "c++0x-style atomics" are, but I'm pretty sure that c++0x mean c++11.

• c++0x refers to c++03 and/or c++07 C++ standards.
• c++1x usually refers to c++11
• c++1y refers to c++11 successor.

Swelter

That's totally incorrect. Both C++0x and C++1x refer to c++11. c++1y refers to either c++14 or c++17, but usually the former. – Burnsides