Re: [Boost-users] multi_index reserve but allocate

Subject: Re: [Boost-users] multi_index reserve but allocate
From: Olivier Tristan (o.tristan_at_[hidden])
Date: 2019-03-20 08:15:03

Hi Joaquin,

My goal is not to be fast but to avoid allocation as I am in a high 
priority thread and I want to avoid possible allocation lock.

I tried the allocator solution following a thread on stackoverflow 
(where you answered as well)

https://stackoverflow.com/questions/37095641/how-to-use-boostobject-pool-as-a-boostmulti-index-allocator

using something like that

 Â boost::pool_allocator<ActiveNote, 
boost::default_user_allocator_new_delete, 
boost::details::pool::default_mutex, 256U, 0U>>;

My issue with this solution is that the pool is actually shared across 
all object using a boost::pool_allocator that requires a mutex as there 
are multiple thread in my app.

One solution could be to tag the allocator but this seems to be not 
possible anymore unless I am mistaken

https://stackoverflow.com/questions/26188586/tag-template-parameter-in-boostpool-allocator-and-boostfast-pool-allocator

Is there a way otherwise to get a pool for each instances of my 
multi_index ?

Thanks !

Le 19/03/2019 à 21:49, Joaquin M López Muñoz via Boost-users a écrit :
> El 19/03/2019 a las 18:14, Olivier Tristan via Boost-users escribió:
>> Hi,
>
> Hi Olivier,
>
>> Looks like that even if I call reserve on a multi_index, it stills 
>> allocate memory while I am still below
>> the reserve size.
>>
>> Is this the intended behavior ?
>
>
> Yes it is. multi_index_container is node based, and, like std 
> node-based containers (std::list, std::set,
> std::unordered_set, etc.), will allocate memory for its nodes as needed.
>
> Hashed and random-access indices provide reserve() member functions 
> (with non-equivalent
> semantics) that control the size of internal contiguous memory chunks 
> maintained by these indices
> additionally to the nodes. So, reserve() (when available) does not 
> (nor is designed to) guarantee
> that no additional memory will be allocated on further insertions.
>
>> If so, what is the best way to avoid allocation in a fixed sized 
>> multi_index
>
> You can write your own allocator that allocates the memory beforehand 
> and then serves it
> piece by piece on allocate(). I suspect, however, that this is not 
> going to be faster than using
> the default std::allocator.
>
>> Thanks !
>
>
> Best,
>
> Joaquín M López Muñoz
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
Olivier Tristan
Research & Development
www.uvi.net