Re: [Boost-users] Boost.Pool - Are you using this library, please can we have your input?

Subject: Re: [Boost-users] Boost.Pool - Are you using this library, please can we have your input?
From: Cory Nelson (phrosty_at_[hidden])
Date: 2011-01-18 17:37:32

On Tue, Jan 18, 2011 at 3:58 AM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
> Boost.Pool is the subject of a 'make-over' by Boost.Guild.
>...
> 2 Â Things missing (or don't work well) from Pool.
> 3  New things that you would like  (this is not a promise!).

It has been some years since I've given up using Pool, so bear with me
if I've forgotten some things about it.  I have often implemented my
own pools, instead.

1. Arenas -- supports allocating any type of any size, and it'll
allocate from larger contiguous blocks like a pool does.  Still
zero-overhead.  Deallocation is a no-op.  Good for creating large
read-only data structures of many types that should all be destroyed
at once.

2. Lock-free versions.  The current global locks make them pretty
useless when you've got allocation-heavy concurrency.  Very simple to
implement if you drop the ordered requirement.

3. Hierarchical pools.  You could for instance have a multi-threaded
arena servicing a multi-threaded pool<4096> servicing a local
single-threaded pool<128>.

4. Don't force object destruction on pool destruction.  Fast
destruction all-at-once is an important feature for pools -- my types
might have useful destructors when the pool is alive, but it might be
the case that none of them matter when the pool is being destroyed.

5. Don't force ordering.  I might not need it.

6. Let me specify alignment.  Useful for SSE which requires 16-byte
alignment for good performance, to generally ensure good locality, and
for concurrency where false sharing in cache lines can be devastating.
 aligned_storage etc. is not enough because it doesn't work for sizes
determined at run-time.

4 and 5 are "shoot your own foot off" features, but seeing how pools
are used for performance, I'd argue that all is fair and it should
have a flexible policy to support it.

-- 
Cory Nelson