在存在allocator重新绑定的情况下，boost :: fast_pool_allocator是否使用null_mutex？

Question

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

我知道以下是一个不安全的实例。每种类型都实例化一个分配器。因此，如果您有两个使用fast_pool_allocator<int, …null_mutex>（例如）的容器，它们将共享相同的分配器实例，从而邀请数据竞争。

以下是一个更大的问题。 allocator接口允许重新绑定。这意味着即使您认为您使用的fast_pool_allocator具有不太可能与其他实例冲突的“本地”类型，容器也可以自由地将该分配器重新绑定到其他类型，例如全局类型，碰撞了。

所以问题是：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和pool_allocator都将   从/向同一个池分配/解除分配。

fast_pool_allocator

也是如此

  

如果在main（）启动之前和之后只有一个线程在运行   main（）结束，然后两个分配器完全是线程安全的。

但是，与其他降低分配开销的方法相比，它们的性能不是很好。我一直在看谷歌的tcmalloc，它创建了每个线程堆以避免锁定。

  

此参数的默认值为boost :: details :: pool :: default_mutex   这是两者的同义词   boost :: details :: pool :: null_mutex（当线程支持是   在编译器中关闭（因此未设置BOOST_HAS_THREADS），或   线程支持已明确禁用   BOOST_DISABLE_THREADS（在线程范围内禁用线程）或   BOOST_POOL_NO_MT（仅限此库））或用于boost :: mutex   （在编译器中启用了线程支持时）。

boost::mutex

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

但如果没有，那么您可能会遇到问题，因为：

  

由于T的大小用于确定底层的类型   池，每个相同大小的不同类型的分配器将共享   相同的底层池。标记类可以防止池   在pool_allocator和fast_pool_allocator之间共享。例如，开启   一个系统，其中sizeof（int）== sizeof（void *），pool_allocator和   pool_allocator将从/分配/取消分配   池。