Reputation: 806
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?
Upvotes: 4
Views: 460
Reputation: 5161
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.
Upvotes: 1