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:47:36

AMDG

Simonson, Lucanus J wrote:
> Steven Watanabe wrote:
>   
>> 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.

Even one long-lived object will make this fail.
It doesn't even have to be really long lived.  It just
has to live long enough for a lot of allocations to be
made.  I like the following better.

>   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.

How exactly would this work?  Would it effectively create a
stack of buffers?

> 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.

This is better but still dangerous because any functions using this method
will not be re-entrant.

>   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.  
>   

In Christ,
Steven Watanabe