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: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-22 18:13:43

AMDG

Christian Schladetsch wrote:
>> Christian Schladetsch wrote:
>>
>>     
>>> I also want to again raise the issue of boost::pool_allocator and
>>> boost::fast_pool_allocator leaking. [snip]
>>>
>>>       
>> Steven> I don't consider this an issue.  All allocators with global state
>> are
>> going to have this problem.  monotonic has a different form of the
>> same problem.
>>     
>
>
> I do not think this is accurate.
>   

I didn't say it was exactly the same.

>> While in your test cases, it is safe to release the
>> memory, in general, if you're using global storage it is not safe to
>> release all the memory, because some other code might still be
>> using it.
>>     
>
>
> But surely that should be left as a responsibility of the client code? At
> least monotonic doesn't leak by default. You can control the memory usage.
>
> With boost::pool_allocator or boost::fast_pool_allocator the user has no
> fair chance of avoiding a leak if either allocator was rebound. Even so, the
> user of these must explicitly release each differently-sized pool which must
> be problematic in general, surely?
>   

The user cannot reliably release the memory allocated
by monotonic, if monotonic is used simultaneously in multiple
independent locations in a program.  This means that only an
application programmer can decide when it is safe to clean up
and libraries cannot safely use monotonic::allocator without
running the risk of allowing memory usage to balloon out
of control.  Further, I shudder to imagine the difficulty of
making sure that this constraint is not violated in a large program.
Okay, now that I've said this much, I realize that the problem is
different.  For monotonic, the memory must be released.  The
problem is that it is hard to do so safely.  For pool_allocator and
fast_pool_allocator, releasing the memory is not critical
because they can reuse memory that has been deallocated.

Anyway, if you want to release memory in this way, you
should be using something like monotonic::local_storage,
to which Boost.Pool has no equivalent.

I'm rapidly concluding that using global storage with
monotonic is much too fragile and dangerous.

In Christ,
Steven Watanabe