Re: [Boost-users] lockfree::spsc_queue & move semantics
From: Bjorn Reese
On 11/09/2014 09:49 PM, Thomas Danckaert wrote:
I'd like to use a spsc_queue of unique_ptr's to bigger objects, to transfer ownership between threads. That way, I can create/allocate an
This limitation inherited from atomic, and I am afraid that it is a bit more complicated than adding a move constructor. Fortunately, there is a C++ proposal to address the problem:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4058.pdf
Is this really the issue here? What I'm trying to do is not the same as what's discussed in the proposal, as the reading/writing of the unique_ptr doesn't have to be an atomic operation in my case. I just want to push a unique_ptr onto the queue, and spsc_queue can store all kinds of objects, which are not atomic either. It only uses atomic operations to keep track of the write and read indices, and those parts of the code don't need to be modified to make this work. As far as I see, the main problem storing unique_ptr's (or any other non-copyable but moveable object), is that the code relies on a copy constructor to store objects in its internal buffer. I added an overload using a move constructor and that seems to work (though I'm quite new to multi-threading or lockfree programming, so I could be missing some potential issues). Thomas
On 11/11/2014 23:56, Thomas Danckaert wrote:
As far as I see, the main problem storing unique_ptr's (or any other non-copyable but moveable object), is that the code relies on a copy constructor to store objects in its internal buffer. I added an overload using a move constructor and that seems to work (though I'm quite new to multi-threading or lockfree programming, so I could be missing some potential issues).
Things get hairier for MP and MC queues (in particular objects may get copied multiple times, which can make moving unsafe), but that shouldn't be an issue for an SPSC queue, so you ought to be fairly safe.
participants (2)
-
Gavin Lambert
-
Thomas Danckaert