Re: [Boost-users] lockfree::spsc_queue & move semantics

Subject: Re: [Boost-users] lockfree::spsc_queue & move semantics
From: Thomas Danckaert (thomasdanckaert+boostusers_at_[hidden])
Date: 2014-11-11 05:56:50

From: Bjorn Reese <breese_at_[hidden]>
Subject: Re: [Boost-users] lockfree::spsc_queue & move semantics
Date: Mon, 10 Nov 2014 20:39:24 +0100

> 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