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: ºÎ×Ó½ÜHzj_jie (hzj_jie_at_[hidden])
Date: 2014-08-05 02:48:58

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_at_[hidden]
> From: gavinl_at_[hidden]
> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users