我想知道使用 set 的安全boost::fast_pool_allocator性null_mutex。
我知道以下是一个不安全的实例。每个类型都实例化一个分配器。因此，如果您有两个都使用fast_pool_allocator<int, …null_mutex>（比如说）的容器，它们将共享相同的分配器实例，因此会引发数据竞争。
更令人担忧的是以下问题。分配器接口允许重新绑定。这意味着即使您认为您正在使用fast_pool_allocator不太可能与其他实例发生冲突的“本地”类型，容器也可以自由地将该分配器重新绑定到不同的类型，例如确实发生冲突的全局类型。
所以问题是： 安全性boost::fast_pool_allocator如何null_mutex？
我相信 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() 结束之后只有一个线程在运行，那么两个分配器都是完全线程安全的。
但是，与其他减少分配开销的方法相比，它们的性能不是很好。我也一直在查看来自 google 的 tcmalloc，它创建每个线程堆以避免锁定。
此参数的默认值为 boost::details::pool::default_mutex ，它是 boost::details::pool::null_mutex 的同义词（当编译器中关闭线程支持时（因此未设置 BOOST_HAS_THREADS），或使用 BOOST_DISABLE_THREADS（Boost-wide 禁用线程）或 BOOST_POOL_NO_MT（仅限此库）或 boost::mutex（在编译器中启用线程支持时）显式禁用线程支持。
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.