Re: [boost] [lockfree] freelist_stack::allocate and freelist_stack::deallocate should not be private

Subject: Re: [boost] [lockfree] freelist_stack::allocate and freelist_stack::deallocate should not be private
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2012-09-02 21:16:47

> >> Currently, the allocate/deallocate functions et.al. in
> >> lockfree::detail::freelist_stack are private. This inhibits reusing
> >> this class for implementing other lock-free datastructures as it's
> >> not possible to allocate anything which has not a constructor taking
> >> 0, 1, or 2 arguments (those are supported explicitly by exposing
> >> overloads for freelist_stack::construct).
> >>
> >> Would it be possible to make the mentioned functions 'protected'
> instead?
> >
> > hm, i see your point. however freelists are not really part of the
> > public API. iac, i'd somehow prefer to have an API like:
> > template <class... Args>
> > T * construct(Args&&... args)

That's be fine with me, but currently you only support up to two constructor
arguments. 

> > but for the time being, making these functions protected is ok to me.
> 
> hm, really not sure about this, mainly because freelist_stack::allocate
> and fixed_size_freelist::allocate have a different interface. but what's
> your specific use case?

We have a lockfree_dqueue implementation which uses freelist_stack
underneath. The elements (nodes) pushed on the queue take 4 constructor
parameters, which makes it impossible to use the current construct()
overloads. Thus we resolve to call allocate() followed by the explicit
construction in place of the new node. 

Adding more constructor overloads (taking more than 2 parameters) would
solve the issue for us as well.

Thanks!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu