Non-POD types in lock-free data structures

4
votes

I want to write lock-free code for non-POD data types; that is, non-trivially destructible and non-trivially constructible classes.

For example, I require pushing to/popping from a multi-producer, multi-consumer lock-free queue of non-POD types.

The boost::lockfree::queue implementation, which appears to be the most production-ready real-time friendly implementation I could find, requires the template type of the queue to be trivially destructible/constructible.

I could refactor my team's 10,000 line codebase to separate the state from the side effects in each class I am concerned with, and then use a Boost lock-free queue of the new POD state-only equivalent of the original type. But, before I do this: is there a different strategy I can use to write lock-free code for these non-POD types?

My understanding is that this is to prevent side effects from the constructor/destructor that are not lock-free/thread-safe. What if the data type is mostly "POD", but the non-trivial constructor/destructor is also a "lock-free" operation, e.g. atomic compare and swap on a static member variable? If this data type is considered safe for use in a lock-free data structure, should I roll my own lock-free queue or is there an equivalently stable implementation I can use instead of the Boost queue?

1
c++multithreadingboostlock-free
Have you looked at Threading Building Blocks? It has a concurrent_queue. - Khouri Giordano
The popular complaint I've heard about TBB's concurrent_queue is that it is technically not lock-free. e.g. Dmitry Vyukov and Jim Dempsey's posts here: software.intel.com/en-us/forums/intel-threading-building-blocks/… - Jackie
@Jackie This may or may not matter in the end, lock free is not magic either. Especially the most general cases (n-producer m-consumer) may actually be faster with locks than lock free. You should try and measure. - Baum mit Augen
Lock-freedom is more about progress guarantees than it is about performance. In most cases it tends to scale better with increasing thread count, but that doesn't necessarily mean it performs better than the locks for all cases. - ivanw

1 Answers

1
votes

You may be able to queue pointers to your objects instead of copies of your objects. Pointers are POD types and can be trivially constructed and destructed.

Of course you need to manage the construction and destruction of your actual objects then, but these are usually local operations not suffering from concurrency problems.