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: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-06-22 18:27:22

Steven Watanabe wrote:
> 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.

I've been thinking about this too.  I have two ideas.  First, put a counter in monotonic that is incremented when allocations happen and decremented when deallocations happen.  If the counter is ever zero you blow away all the buffers automatically.  Second, you create a scoped object that encapsulates the idea of the monotonic storage's lifetime and delete the buffers when the object is destructed.  Finally, you add a template parameter to monotonic to allow many programmers working in the same application to declare their own monotonic type that has separate buffers and lifetime from eachother.  In this way managing the memory owned monotonic can be easy and safe.  The only problem left is therefore misuse.  I'm trying to understand the risk of misuse, and it looks like running out of memory is the primary risk.

Perhaps I missed this part of the discussion, but why is it named monotonic?  I would think something that describes its intended usage would be better.  boost::scratch_memory, for example.  Anyone who keeps objects allocated with an allocator called scratch_memory around for the lifetime of his program has some obvious explaining to do.  I also think that a more general interface would be to allow the user to supply and address and size of memory to use as the initial scratch memory with the automatic (on by default) ability to grow beyond that buffer if needed with system allocation on the heap using the chain.  Thread safty should be controlled by a template parameter and enabled by default.  

Luke