c++ - 在存在分配器重新绑定(bind)的情况下，使用 null_mutex 的 boost::fast_pool_allocator 是否安全？

Question

我想知道使用 boost::fast_pool_allocator 的安全性与 null_mutex放。

我知道下面是一个不安全的实例。每个类型都实例化一个分配器。所以如果你有两个容器都使用 fast_pool_allocator<int, …null_mutex> (比如说)，它们将共享同一个分配器实例，因此会引发数据竞争。

更令人担忧的是以下内容。分配器接口(interface)允许重新绑定(bind)。这意味着即使您认为您正在使用 fast_pool_allocator对于不太可能与其他实例发生冲突的“本地”类型，容器可以自由地将分配器重新绑定(bind)到不同的类型，例如确实会发生冲突的全局类型。

所以问题是:boost::fast_pool_allocator 到底有多安全？与 null_mutex ？

Answer 1

我相信 pool_allocator 和 fast_pool_allocator 都是线程安全的，

来自: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.

fast_pool_allocator 也是如此

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

然而，与其他减少分配开销的方法相比，它们的性能不是很好。我也一直在查看来自谷歌的 tcmalloc，它为每个线程创建堆以避免锁定。

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

是为我设置的，这就是为什么在我的线程测试中我没有问题 - 我猜这也会为你正确设置。

但如果不是，那么您可能会遇到问题，因为:

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.