[Boost-users] lockfree::spsc_queue & move semantics
768 views
Skip to first unread message
Thomas Danckaert
Nov 9, 2014, 7:31:04 PM11/9/14
to boost-users
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
object in a non-realtime thread, then transfer ownership to a realtime
thread using a lockfree queue, and, using another queue, pass on the
unique_ptr to another thread that takes care of cleanup when the
realtime thread no longer needs the it.
For example:
boost::lockfree::spsc_queue<unique_ptr<string>,
boost::lockfree::capacity<10> > cb;
Unfortunately, spsc_queue does not use move semantics (methods to push
onto the queue take parameters as const reference and construct a copy
in the queues internal storage), so i can not cb.push() a
unique_ptr<string> onto my queue. Is it reasonable to want to add
this, and if so, what would be the best place to submit a request? (I
managed to get a simple example working by adding rvalue reference
overrides of the queue's push() methods, and using std::move in the
pop() method)
bool push(T && t) { };
Also, I noticed that the destructor for the spsc_queue (with size
fixed at compile-time) does not run destructors for it's contents.
What could be the reason for this?
Thomas
transfer ownership between threads. That way, I can create/allocate an
object in a non-realtime thread, then transfer ownership to a realtime
thread using a lockfree queue, and, using another queue, pass on the
unique_ptr to another thread that takes care of cleanup when the
realtime thread no longer needs the it.
For example:
boost::lockfree::spsc_queue<unique_ptr<string>,
boost::lockfree::capacity<10> > cb;
Unfortunately, spsc_queue does not use move semantics (methods to push
onto the queue take parameters as const reference and construct a copy
in the queues internal storage), so i can not cb.push() a
unique_ptr<string> onto my queue. Is it reasonable to want to add
this, and if so, what would be the best place to submit a request? (I
managed to get a simple example working by adding rvalue reference
overrides of the queue's push() methods, and using std::move in the
pop() method)
bool push(T && t) { };
Also, I noticed that the destructor for the spsc_queue (with size
fixed at compile-time) does not run destructors for it's contents.
What could be the reason for this?
Thomas
Bjorn Reese
Nov 10, 2014, 2:39:32 PM11/10/14
to boost...@lists.boost.org
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
> 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
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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thomas Danckaert
Nov 11, 2014, 5:56:57 AM11/11/14
to boost-users
From: Bjorn Reese <bre...@mail1.stofanet.dk>
Subject: Re: [Boost-users] lockfree::spsc_queue & move semantics
Date: Mon, 10 Nov 2014 20:39:24 +0100
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
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
quang...@gmail.com
Nov 15, 2014, 1:57:22 PM11/15/14
to boost...@lists.boost.org
------Original Message------
From: Bjorn Reese
Sender: Boost-users
To: boost...@lists.boost.org
ReplyTo: boost...@lists.boost.org
Subject: Re: [Boost-users] lockfree::spsc_queue & move semantics
Sent: Nov 10, 2014 2:39 PM
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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sent from my BlackBerry device on the Rogers Wireless Network
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Gavin Lambert
Nov 24, 2014, 2:15:43 AM11/24/14
to boost...@lists.boost.org
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
> 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).
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.
Reply all
Reply to author
Forward
0 new messages