Boost.Pool - Are you using this library, please can we have your input?
Boost.Pool is the subject of a 'make-over' by Boost.Guild. (This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox). In order to permit any modification, the original (hand-written?) html documentation has been converted to Quickbook (and somewhat revised) at http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/ You can build the html docs using the jamfile.v2 in the normal way, but you will probably find it more convenient to go direct to the pdf version http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf This is fairly fully hyperlinked, and includes a reference section using Doxygen. Doxygen comments have been added to the header files (from the original html docs). (If you are a Doxygen fan, there is also a Doxyfile for generating Doxygen-style docs in the /doc/Doxygen/ folder). We are now considering some better tests, and perhaps some enhancements to the code. We'd like input from users about: 1 Things missing or wrong from the docs. More up to date references? 2 Things missing (or don't work well) from Pool. 3 New things that you would like (this is not a promise!). 4 Examples of your use. Perhaps you built some during your development that could be used? 5 Better tests. Thanks. Paul PS Don't panic - the release version will not be changed without a mini-review. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Tue, 18 Jan 2011, Paul A. Bristow wrote:
Boost.Pool is the subject of a 'make-over' by Boost.Guild.
(This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox).
(snip)
We are now considering some better tests, and perhaps some enhancements to the code.
We'd like input from users about:
1 Things missing or wrong from the docs. More up to date references?
2 Things missing (or don't work well) from Pool.
Using pools with small allocation chunks (to get behavior like malloc/new) is very slow. It might be nice to have a type of pool that keeps variable-sized blocks, like current malloc implementations do.
3 New things that you would like (this is not a promise!).
The ability to store the pool metadata outside the pool itself. The case where one would use this is when the pool is being used to allocate a special kind of memory, and the pool metadata (headers and free list) doesn't need to be in that kind of memory. A shared_ptr deleter for objects allocated from pools. A pool UserAllocator that gets its memory from another pool (to allow a pool of large blocks to be broken into smaller pieces to store individual objects). A thread-safe pool (preferably including lock-free or semi-lock-free algorithms when possible).
4 Examples of your use. Perhaps you built some during your development that could be used?
I was using a pool (simple_segregated_storage) to manage pages of memory that are registered with GASNet for message passing. In its fastest mode, GASNet requires a contiguous block of memory to be registered when the program starts, and I used a pool to allocate data structures in this block. Additionally, a pool is a safe way to allocate memory in a signal context (since it is possible to lock accesses to the pool), while malloc/... are not signal-safe. -- Jeremiah Willcock
On Tue, Jan 18, 2011 at 3:58 AM, Paul A. Bristow <pbristow@hetp.u-net.com> 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
participants (3)
-
Cory Nelson -
Jeremiah Willcock -
Paul A. Bristow