Q: ReaderWriterQueue on non-primitive types allowed? about readerwriterqueue HOT 5 CLOSED

Yep, this is possible, and supported. It should be thread-safe. If it's not, that's a huge bug which I'd love a reproducible test-case for! :-)

The elements are copied (or moved, if possible) into internal storage (just like std::vector, for example) during an enqueue, and moved back out during a dequeue. The internal bookkeeping makes the reservation of the slot to store the element in (and dequeue it afterwards) thread-safe. The code does not differentiate between primitive types like int and complex user types -- the only difference is that the constructor and destructor calls compile to no-ops for POD-types.

Note that boost::lockfree::queue has several restrictions, but it's usable from many threads at once, whereas mine has almost no restrictions except that it's usable only by a maximum of two threads (one producer and one consumer). Apples and oranges, I'm afraid.

from readerwriterqueue.

Thanks for the fast reply and explanation.

from readerwriterqueue.

Sure, no problem.

from readerwriterqueue.

Did you ever consider to apply for integration in boost::lockfree? I know that the review process for boost is cumbersome but I believe it is worth to try since this functionality (lockfree single producer/single consumer queue that works on non-primitive data types) really is missing.

My test application was a simple line-based text compare tool where two producer threads fill two queues and one consumer thread pops them and does the comparison.

from readerwriterqueue.

Hmm, no I hadn't. I'm not a super huge fan of Boost, mostly because I find it cumbersome to integrate into projects (it's got a lot of awesome stuff in it, but it's one heck of a dependency to pull in for small projects). If somebody else wants to integrate it into Boost that's fine by me, but I don't have the time to pursue it myself.

As far as I can tell, Boost's wait-free single-producer single-consumer queue does support non-primitive data types (just not dynamic resizing of the queue), though I'm not sure it supports move semantics.

from readerwriterqueue.