アプリケーションで6つのスレッドを継続的に実行しています。シナリオは次のとおりです。
1つのスレッドが継続的にメッセージを取得し、メッセージキューに挿入します。他の4つのスレッドは、キューからメッセージを継続的にフェッチして処理するワーカーと見なすことができます。もう1つの最後のスレッドは、分析情報を入力します。
問題：
現在、メッセージスレッドを取得するためのスリープ時間は100msです。ワーカースレッドは200msです。このアプリケーションを実行すると、メッセージフェッチスレッドが制御を取得してキューに挿入し、ヒープを増やします。ワーカースレッドは、メッセージを処理して割り当てを解除する機会を得ていません。最後に、その結果、メモリが不足します。
メッセージフェッチスレッドとワーカースレッドに機会均等が与えられるように、この種のシナリオを管理する方法。
前もって感謝します ：）
プロデューサースレッドにバックプレッシャを追加する必要があります。通常、これはブロッキングコンシューマープロデューサーキューを使用して行われます。プロデューサーはアイテムをキューに追加し、コンシューマーはアイテムをキューからデキューして処理します。キューが空の場合、プロデューサーがキューに何かを追加するまで、コンシューマーはブロックします。キューがいっぱいの場合、コンシューマーがキューからアイテムをフェッチするまでプロデューサーブロック。
私がよく使用するフロー制御システムの 1 つは、起動時にメッセージ オブジェクトの大きなプールを作成し、それ以上作成しないというものです。*オブジェクトは、スレッド セーフなブロッキング 'プール キュー' に格納されて循環し、プロデューサーによってプールからポップされ、他のブロッキング キューのコンシューマーにキューイングされ、'消費' されたときにプール キューにプッシュされます。 .
これにより、メモリの使用量が制限され、フロー制御が提供され (プールが空になると、メッセージがコンシューマーから返されるまでプロデューサーがブロックします)、継続的な new/delete/malloc/free が排除されます。より複雑で低速な制限付きキューは必要なく、すべてのキューが、(既知の) 最大メッセージ数を保持するのに十分な大きさであればよいだけです。
「クラシック」ブロッキング キューを使用する場合、Sleep() 呼び出しは必要ありません。
制限付きキューを使用すると、いっぱいになると、より多くのスペースが使用可能になるまで、エンキューしようとするスレッドがブロックされます。
tbbからconcurrent_bounded_queueを使用するか、最大キューサイズに初期化されたセマフォを使用して、エンキューでデクリメントし、デキューでインクリメントすることができます。boost :: threadはセマフォをネイティブに提供しませんが、ロックと条件変数を使用して実装できます。
あなたの質問は少し曖昧なので、コードの代わりにこれらのガイドラインを与えることができます：
C ++ 11のスレッドライブラリには、コンシューマプロデューサアプリケーションを実装するために必要なすべてのものが含まれています。ただし、コンパイラをアップグレードできない場合は、ブーストスレッドライブラリを使用することもできます。