13

私はマルチスレッド プログラミングの初心者で、最も一般的な Producer-Consumer-Queue を知っているだけです。Boost C++ ライブラリを使用していますが、boost::lockfree::queue を使用するのがよいのか、それとも「mutex」と「condition_variable」を使用する std::queue のラッパー クラスを使用するのがよいのかわかりません。

ロックフリーのデータ構造を使用するのが良いのはどこで、「mutex」と「condition_variables」に基づく単純な実装を使用するのが良いのはどこですか?

4

4 に答える 4

4

また、ロックフリー キューを使用して、リアルタイム アプリケーションでの優先順位の逆転を回避することもできます。

たとえば、Android の OpenSL は、優先度の高いスレッドでオーディオ バッファー キュー コールバックを提供します。このスレッドが優先度の低いスレッドによって保持されているロックを待機する必要がある場合、優先度の高いスレッドのスケジューリングは無意味になり、コールバックが不規則になり、オーディオ バッファーが不足し始める可能性があります。これにより、不快なポップ音が発生します。

于 2014-04-08T21:05:48.687 に答える
2

この決定は、「解決すべきタスクにとってロックの競合は問題になるでしょうか?」という質問に要約されます。

並行環境でのロックは、2 つの異なる問題に対処します

  • 正確性: コードが実際に意図したとおりに動作することを確認します。他のスレッドからの干渉を防ぎます。
  • スループット/スケーラビリティ: システムを通過する同時操作の持続的な高「フロー」を可能にします。リソースを追加して、システムのパフォーマンスをスケールアップできるようにします。

これらの 2 つの懸念事項は、対立する目標です。古典的なアプローチは、共有データ構造をグローバル ロックで保護することです。これにより 100% の正確性が保証されますが、共有ロックが「トラフィックの輻輳」につながるため、パフォーマンス、特に一定以上の同時実行レベルのスケールアップが妨げられます。

ちなみに、「ロックフリー」という言葉の使い方には注意が必要です。厳密に言えば、共同作業は 100% ロック フリーではありません。ただし、同じ要素に同時にアクセスする必要があるパートナーへのブロックの影響を軽減するために、コラボレーションを巧みに調整することは可能です。

于 2014-03-07T16:55:19.643 に答える