Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB

Subject: Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-22 22:09:03

On Tue, Jun 23, 2009 at 12:29 PM, Felipe Magno de Almeida <
felipe.m.almeida_at_[hidden]> wrote:

>
> I think you should just not support some STL implementations.

As it currently stands, monotonic is perfectly safe and compliant for all
STL implementations.

One problem, which Steven pointed out, is that different areas of the same
program can cause issues if one releases global monotonic storage without
the consent from or knowledge of another part.

Equivalently, one can store an iterator into a vector V in one object, and
another object can resize V, invalidating that iterator.

Is this a fault of std::vector? Well, no. It is in the documentation that
resizing a vector may invalidate any iterators. You also can't safely
dereference a freed pointer.

For monotonic, the problem is admittedly trickier because, in general, you
*do* want to have different parts of the program using monotonic allocators
and you don't necessarily want them to interact. This is one reason I was so
stubborn about dropping the idea of:

storage<> store;
std::list<int, monotonic::allocator<int> > list(store);

Over using a global store. But, I had to at the end, to ensure that it
worked for STL implementations other than MSVC.

There are currently two ways keep locality with the proposal as it stands.
First, you can use a local scope:

monotonic::local<> storage;
{
    // do stuff using whatever monotonic::allocator<T> you wish; it wont
affect
    // other parts of the application, and this is reentrant

    // however, here be dragons if you intermix with monotonic containers
created
    // before this scope was entered (outside of MSVC).

    // you can also use the storage directly:
    string &s = storage.create<string>("foo");
    array<int, 64> &nums = storage.create<array<int, 64> >();

    storage.destroy(s);
}
// resources are freed when storage leaves scope

Another way is to use regions, via monotonic::region_allocator<T, N>. This
can be readily changed to be allocator<T,U> for some user-supplied tag-type
U rather than a compile-time constant, as Steven has suggested.

We should have interprocess STL implementation moved to a new
> namespace in boost.

What we really need is a STL implementation that allows for stateful
allocators, as Stepanov first envisaged.

I have monotonic::extra::vector, list, map, set etc. These are just wrappers
for std::containers that respect allocators correctly.

It would be best to have a general set of containers that also respect
stateful allocators; interprocess would benefit from this as well. However,
there are deeper issues there than I am able or want to address right now.

> And have monotonic only supports C++0x allocators
> concept.

It works as it stands, with local<> and regions providing tools necessary
for safe isolation.

Regards,
Christian.