Re: [Boost-users] why lockfree/queue.hpp requires has_trivial_assign and has_trivial_destructor to template type T

Subject: Re: [Boost-users] why lockfree/queue.hpp requires has_trivial_assign and has_trivial_destructor to template type T
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-08-04 18:42:27

On 4/08/2014 21:39, 何子杰Hzj_jie wrote:
> as new to boost, i am looking for a solution to combine
> boost::lockfree::queue with std::function, i.e.
> boot::lockfree::queue<std::function>, but unfortunately, the
> implementation of the lockfree queue required the T to be trivial
> assignable and trivial destructible.
> with some basic investigation to the implementation of
> boost::lockfree::queue, the assignment operator is using when pop or
> unsynchronized_pop, it calls detail::copy_payload, which is using
> operator= or constructor and operator=. though overloaded assignment
> operator may use more time and cause the pop function to wait for longer
> time, i do not see it would block the logic.
> for the destruction, queue implementation always calls pool.template
> destruct instead deallocate, which means even for a default destructor,
> it will also be called.
>
> so is this a defect or by-design behavior of the lockfree queue?

I asked the same question a while ago; it's by design.

I don't recall the exact specifics, but I think the issue is that there 
are some cases when the payload object can be destroyed twice or copied 
after being destroyed, which can only be safe if the object has those 
trivial properties.

A bare pointer does have those trivial properties, so if you don't mind 
additional allocation/deallocation on push/pop you can store a 
function<>* instead of the function<> itself.

(There are ways to make lockfree queues that don't have to require these 
properties, but typically you have to sacrifice some flexibility, eg. 
MPSC instead of MPMC.)