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 19:49:37

> Steven> The user cannot reliably release the memory allocated
> by monotonic, if monotonic is used simultaneously in multiple
> independent locations in a program.

This is true, and why I added regions.

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

However, if you pass a container  that uses a monotonic allocator to a
library, you should know what that library will do with it. I also added
chain<> to help with the most obvious problem of vector resizing, however
this doesnt help in the general case. But even so, the user can control and
limit the amount of memory used by using a region with a fixed-size storage.

In general, I agree that there is a wide scope for misuse. There is a good
case for adding an introspection system to debug builds that self-monitors
and warns the user about probable problems.

It can be argued that any system that needs this is too risky to use.

> Further, I shudder to imagine the difficulty of
> making sure that this constraint is not violated in a large program.

Again, regions and local<> provide what is needed to manage this.

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.

See above.

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

I agree that there are risks. Perhaps it can be renormalised so that the
default allocator has to be supplied with a region and uses thread-safety by
default?

allocator<int, Region> default; // region is required, uses shared_storage
allocator<int, Region, monotonic::global_tag> alloc; // uses single global
storage
allocator<int, Region, monotonic::local_tag> alloc; // uses thread local
storage

Would this alleviate some of your concerns?

> In Christ,
> Steven Watanabe
>

Regards,
Christian