Re: [boost] [shmem] Multiple allocator inheritence in containers

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-17 10:48:20

Hi Tom,

> I noticed in the shmem implementation of the node based containers, 
> multiple inheritence of allocators is used to provide the allocators of 
> the three types required. This is going to add something like 8 extra 
> bytes of overhead to the container for a allocator type of size 4, 
> compared to having only a single allocator base class.
> 
> Is there any reason not to create copies of a single allocator on 
> demand? e.g. something like this:

Some allocators are expensive to copy-construct. For example, 
boost::shmem::node_allocator<T> shares the same pool with other 
node_allocator<Y> instances of the same segment if sizeof(T)==sizeof(Y). 
The common pool must be searched in run time in the segment (you can't 
do the static pool trick like in multithreaded applications), and Shmem 
emulates this using "unique instance" mechanism, that basically 
constructs a map of objects created using this "unique instance" 
services indexed by name. So when creating that node allocators, the 
instance must search the common pool and create it if it is not already 
created (and do all this atomically holding a mutex).

So constructing a node allocator is not cheap, and it can be quite 
expensive if there are many "unique instance" ("pseudo-singleton") 
variables. Dinkumware STL implementation also stores all allocators in 
the container. Shmem allocators have an optimization if the 
allocator::pointer has trivial constructor, and just stores two 
allocators instead of three. But if the allocator has an enhanced 
construct function:

template<class Convertible>
construct (const Convertible &convertible);

instead of

construct (const T &value);

it can define an specialization of 
boost::shmem::has_convertible_construct<> so nodes can be constructed 
from the value_type directly. In this case, the container just stores 
one allocator. As you can suppose, all Shmem allocators have convertible 
construct. This optimization is described in the documentation.

This problem is likely to change soon as rvalue reference standard 
proposal changes the construct function to a template:

template<class T>
construct (const T &&value);

using T as a convertible type we can have less allocators stored without 
extensions. I don't like much that construct just allows one parameter. 
If the target type has a more complex constructor, we could take 
advantage in node constructors, because the container is who defines the 
node class.

Regards,

Ion