問題タブ [boost-pool]

バックグラウンド

以前の質問により、 boost.poolboost.poolを詳細に調査することになりましたが、理解を深めるための補足的な質問があります。

前奏曲

このリファレンスでは、オブジェクト プール パターンについて次のように述べています。

オブジェクト プール パターンは、必要に応じてオブジェクトを割り当てて破棄するのではなく、すぐに使用できるように保持された初期化済みオブジェクトのセットを使用するソフトウェア作成設計パターンです。

私が知る限り、boost.pool(単純化された) は、主に のサイズに基づくメモリの割り当てと管理によってオブジェクト プール パターンを実装element_typeし、割り当てられたオブジェクトへの単純なポインターを返します。

free簡単なブーストの例は、取得した要素を明示的に指定する必要がないことも示しています。

質問

割り当てられたメモリがプール オブジェクトの破棄時に安全に解放されることは理解していますが、クライアントによって取得されたメモリのブロックが解放されてプールに戻され、インターフェイスが直接ポインタを返す場合に再利用可能であることをプールはどのように認識しますか?へelement_typeの呼び出しfree()はまだ必要ありませんか? つまり、メモリがまだ使用されていないことが確実でない場合、ブースト プールはどのようにしてこのメ​​モリを再利用できますか? そして、このメモリを再利用しない場合、これは wiki リファレンスで説明されているものと同じパターンと見なされますか?

静的メモリ プロバイダーとしてブースト プールを使用していますが、

上記のコードで、プールのサイズを修正する方法は、boost::pool が静的メモリ アロケータとして提供することを知っていることを意味しますが、このプールのサイズを修正することはできません。そのサイズを制限します。たとえば、200 チャンクのみのプールが必要なので、その後 200 チャンクを取得できますが、NULL でこれを行う方法を教えてください

Boost ライブラリのかなり制限された機能をプロジェクトに追加しようとしました。つまり、「pool_allocator」クラスの助けを借りてプールから小さなオブジェクトにメモリを割り当て、プロジェクトの依存関係を 4 つのデバッグ スタティック ライブラリに追加する必要があることを発見しました。ファイルと 4 つのリリース スタティック ライブラリ ファイル。つまり、次のような 1 行に 8 つのライブラリ ファイルの依存関係が必要です。

静的ライブラリにリンクせずにこれらのクラスを使用する方法はありますか? (おそらく、テンプレート パラメータの特定の組み合わせでしょうか?)

std::vectorを使用して割り当てられたオブジェクトを使用して、のオブジェクトが必要ですboost::pool。このようなものは正しいですか：

このコードは機能しますが、その理由は完全にはわかりません。私はアロケーターの概念にまったく慣れていませんが、正しく理解していればstd::vector、デフォルトのアロケーターの代わりにプールを使用するように指示されているため、ベクターで作成された要素はすべてプールから作成されます。

私が正確に確信していないのは、次のとおりです。

プールはどこですか？

また、プールに直接アクセスするにはどうすればよいでしょうか (たとえば、メモリを解放するため)。

プールが含まれていますかfast_pool_allocator、またはプールを個別に作成し、アロケーターにそれを使用するように指示する必要がありますか。

だから私はmemory_poolsブーストプールに基づいてこのコンテナアロケータクラスを作りました:

memory_pools.hpp

memory_pools.ipp

次に、次を使用してテストします。

macOSX 10.10 で clang3.5 を使用すると、次のようになりました。

一方、起動すると：

私は持っている：

質問

ブーストプールを使用したメモリ割り当てはそれほど遅いはずですか、それとも私のテストは何らかの理由で無効ですか?

編集

Carmeronのコメントの後、フラグ-O3と-DNDEBUGフラグを追加しました。

memory_poolsバージョン、および:

標準のアロケータ バージョンの場合。

質問

質問はまだありますが、遅いのは正常ですか?

次の簡単なテストコードがあります。

このコードを Clang または GCC でコンパイルすると、次の出力が得られます。

boost::pool_allocatorusingによってコンパイラが move コンストラクターを使用できないのはなぜですか?
何か不足していますか？

クイックフィックス(1.13.3)の下でブーストの fast_pool_allocator (バージョン 1.55) を使用する高度にスレッド化されたアプリケーションがあります。アプリケーションは 1 日の間に多数のオブジェクトを割り当て、シャットダウンするまで多かれ少なかれ直線的に増加し、1 日の終わりまでに 32G 程度の仮想メモリを使用します。アプリケーションの仮想メモリ フットプリントが増大するのを見ると、ほとんどの割り当ては 200MB 程度です。しかし、通常はその日の後半のある時点で、アプリケーションを介したトランザクションの流れが実質的に変化していなくても、boost は 6GB の割り当てを行うことを決定します。

アロケーターのコードを見ると、割り当て後に最初にブーストが行われ、新しいブロックがチャンクに設定されます。関数はsimple_segregated_storage<SizeType>::segregatesimple_segregated_storage.hpp:280 にあります。デバッガーをプロセスにアタッチし、巨大な割り当てが発生すると、その関数の実行に (当然のことながら) 長い時間がかかることを観察しました。具体的には、302 行目の for ループです。20 ～ 30 秒かかり、そのコードはミューテックスで保護されているため、アロケーターで何かをしようとする他のすべてのスレッドがブロックされます。これはお客様を怒らせます。

質問:

1. その前に 1 日中常に ~200MB のブロックを要求していたのに、突然 6GB を割り当てたのはなぜですか?
2. 割り当てを何らかの方法で制限できますか? 小さいピースをもっと頻繁に求めてもらいたいです。
3. これは間違ったアロケーターですか？これはクイックフィックスの開発者に対する質問だと思いますが、これが彼らの好む方法のようです。アロケータを使用するオブジェクトは、主にstd::mapとstd::multimapです。