boost::fast_pool_allocatorセットで使う安全性が気になりましたnull_mutex。
以下は安全でないインスタンスであることを知っています。アロケーターは型ごとにインスタンス化されます。したがって、両方がfast_pool_allocator<int, …null_mutex>(たとえば) 使用する 2 つのコンテナーがある場合、それらは両方とも同じアロケーター インスタンスを共有するため、データ競合が発生します。
それよりも気になるのは以下。アロケーター インターフェイスでは、再バインドが可能です。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() の終了後に実行されているスレッドが 1 つだけの場合、両方のアロケーターは完全にスレッドセーフです。
ただし、割り当てオーバーヘッドを削減する他の方法と比較すると、あまりパフォーマンスが高くありません。また、ロックを回避するためにスレッドごとのヒープを作成する Google の 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 の両方が同じプールに対して割り当て/割り当て解除を行います。