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

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], 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::queuestd::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