c++ - C++ 11 でスレッドが枯渇するのを防ぐ方法

Question

スレッドが枯渇するのを防ぐロック ポリシーが C++11 にあるかどうか疑問に思っています。

1 つのミューテックスをめぐって競合するスレッドが多数あります。さて、私の問題は、クリティカルセクションを離れているスレッドがすぐに同じミューテックスを求めて競合し、ほとんどの場合勝つことです。したがって、ミューテックスを待機している他のスレッドは飢えています。

クリティカル セクションを残して、他のスレッドにミューテックスをロックする機会を与えるために、スレッドを最小限の時間だけスリープさせたくありません。

ミューテックスで待機しているスレッドの公平なロックを有効にするパラメーターが必要であると考えましたが、適切な解決策を見つけることができませんでした。

スレッド実行の順序を再スケジュールすることを想定している std::this_thread::yield() 関数を見つけましたが、これはスケジューラ スレッドへのヒントにすぎず、スレッドを再スケジュールするかどうかはスケジューラ スレッドの実装に依存します。

C++11 で同じミューテックスを待機しているスレッドに公平なロック ポリシーを提供する方法はありますか? 通常の戦略は何ですか？

ありがとう

Answer 1

これは、同じスレッドが再びミューテックスを取得できる場合に、タスクの切り替えに時間を浪費しないように設計された、ミューテックスの一般的な最適化です。現在のスレッドのタイム スライスにまだ時間が残っている場合は、ミューテックスを一時停止するのではなく取得させ、別のスレッドに切り替えることで、1 秒あたりに実行されるユーザー命令の点でより多くのスループットを得ることができます。キャッシュ ラインの大量のリロードとその他のさまざまな遅延)。

これが問題になるほど多くの競合がミューテックスにある場合は、アプリケーションの設計が間違っています。これらすべてのスレッドがミューテックスでブロックされているため、何もしていません。おそらく、それほど多くのスレッドがないほうがよいでしょう。

複数のスレッドがミューテックスをめぐって競合する場合に、どのスレッドがロックを取得しても問題にならないように、アプリケーションを設計する必要があります。直接競合もめったに発生しないはずです。特に、多数のスレッドでの直接競合はそうです。

これが問題ないシナリオだと私が考えることができる唯一の状況は、すべてのスレッドが条件変数を待機しており、それがブロードキャストされてすべてのスレッドが起動される場合です。その後、すべてのスレッドがミューテックスを求めて競合しますが、これを正しく行っている場合は、すべてのスレッドがこれが誤ったウェイクではないことを簡単に確認してから、ミューテックスを解放する必要があります。それでも、これは「雷鳴の群れ」状況と呼ばれ、これらすべてのスレッドをシリアル化するため、理想的ではありません。