Question

I was wondering about the safety of using boost::fast_pool_allocator with null_mutex set.

I know that the following is an unsafe instance. An allocator is instantiated per type. So if you have two containers which both use fast_pool_allocator<int, …null_mutex> (say), they will both share the same allocator instance, and hence invite data races.

A greater concern is the following. The allocator interface allows rebinding. This means that even though you think you are using the fast_pool_allocator with a ‘local’ type which is unlikely to collide with other instances, a container is free to rebind that allocator to a different type, such as a global one, which does collide.

So the question is: Just how safe is boost::fast_pool_allocator with null_mutex?

Answer 1

I believe that both pool_allocator and fast_pool_allocator are thread safe,

from: http://www.boost.org/libs/pool/doc/html/header/boost/pool/pool_alloc_hpp.html

pool_allocator and pool_allocator will both
allocate/deallocate from/to the same pool.

As will the fast_pool_allocator

If there is only one thread running before main() starts and after
main() ends, then both allocators are completely thread-safe.

however they are not very performant compared to other ways of decreasing allocation overhead. I have also been looking at tcmalloc from google which creates per thread heaps to avoid locking.

The default for this parameter is boost::details::pool::default_mutex
which is a synonym for either
boost::details::pool::null_mutex (when threading support is
turned off in the compiler (so BOOST_HAS_THREADS is not set), or
threading support has ben explicitly disabled with
BOOST_DISABLE_THREADS (Boost-wide disabling of threads) or
BOOST_POOL_NO_MT (this library only)) or for boost::mutex
(when threading support is enabled in the compiler).

boost::mutex

was set for me which is why in my threaded tests I had no issue – I would guess that this will be set correctly for you also.

But if not then you could have an issue because:

Since the size of T is used to determine the type of the underlying
Pool, each allocator for different types of the same size will share
the same underlying pool. The tag class prevents pools from being
shared between pool_allocator and fast_pool_allocator. For example, on
a system where sizeof(int) == sizeof(void *), pool_allocator and
pool_allocator will both allocate/deallocate from/to the same
pool.