thank you for the information Gavin.

it looks like an implementation limitation to me. the pointer surely works, but it will cause trouble about the instance lifetime. my scenario is a threadpool, which will work on functions / lambdas [function<bool(void)>], so let the threadpool queue keeps the instances would be an easy approach. but multi-produce-multi-consume is required.

i will try to implement another version, and loose the limitations. hope my knowledge is enough to handle it.

.Hzj_jie

> To: boost-users@lists.boost.org
> From: gavinl@compacsort.com
> Date: Tue, 5 Aug 2014 10:42:27 +1200
> Subject: Re: [Boost-users] why lockfree/queue.hpp requires has_trivial_assign and has_trivial_destructor to template type T
>
> 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.)
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users