3

メインスレッドと診断スレッドを備えたプログラムがあります。メイン スレッドは基本的に、while(1)さまざまなタスクを実行するループです。これらのタスクの 1 つは、診断エンジンにシステムに関する情報を提供し、後で (次のループで) 再度チェックして、対処すべき問題がないかどうかを確認することです。メイン ループの反復には、0.1 秒以上かかることはありません。すべてが順調であれば、診断エンジンはほとんど時間をかけずに答えを返します。ただし、問題がある場合、診断エンジンが問題を特定するのに数秒かかることがあります。このため、診断エンジンは新しい情報を受け取るたびに、新しい診断スレッドを起動します。

私たちが抱えている問題は、診断スレッドがメイン スレッドから時間を盗んでいることです。事実上、2 つのスレッドがあっても、診断スレッドがまだ回転しているため、メイン スレッドは思うように頻繁に実行できません。

Boost スレッドを使用して、スレッドが別のスレッドに移動する前に実行できる時間を制限することは可能ですか? また、ここで重要なのは、使用している診断アルゴリズムがブラックボックスであるため、その中にスレッド コードを配置できないことです。ありがとう！

4

4 に答える 4

2

スレッドがインターロックされているように見えるため、メインスレッドはバックグラウンドスレッドが作業を完了するまで待機します。これを引き起こす可能性のあるマルチスレッド同期を確認してください。

OS スケジューリングに関係がないことを確認するには、プログラムをダブルコア システムで実行します。これにより、両方のスレッドを実際に並行して実行できます。

于 2010-09-20T22:31:17.367 に答える
2

複数のスレッドを実行すると、実際に CPU 時間が消費されます。プロセッサが 1 つしかなく、1 つのスレッドがプロセッサを集中的に使用する作業を行っている場合、そのスレッドは他のスレッドで行われる作業を遅くします。OS 固有の機能を使用してスレッドの優先度を変更すると、診断スレッドの優先度をメイン スレッドよりも低くすることができます。また、診断スレッドが「回転」していると述べています。文字通り、次のようなスピン待機に相当するということですか。

while(!check_done()) ; // loop until done

もしそうなら、何も達成せずにCPU時間を消費するので、そのようなビジーウェイトを避けることを強くお勧めします.

ただし、複数のスレッドが相互に速度を低下させる可能性はありますが、実際に数秒の遅延が見られる場合は、別の問題があり、メイン スレッドが診断スレッドの完了を実際に待っていることを示しています。join()診断スレッドの呼び出しがメイン ループの外にあることを確認します。

別の可能性としては、診断スレッドがメイン スレッド ループに必要なミューテックスをロックしている可能性があります。ロックされているミューテックスとその場所を確認します。

本当に役立つには、いくつかのコードを見る必要があります。

于 2010-09-21T09:51:33.187 に答える
0

通常、OS レベルではこれを行うことはできないため、実行時間を制限するためにブーストに固有のものがあるとは思えません。小さなブロック操作と待機でちょっと偽造することはできますが、きれいではありません。

スレッドまたはプロセス レベルでプロセッサ アフィニティを調べることをお勧めします (これは OS 固有になります)。診断処理をマルチコア マシン上の [論理] プロセッサの限られたサブセットに分離できれば、メイン プロセスに関連する最大実行量を制御する非常に簡単なメカニズムが得られます。これは、同様のことをしようとしたときに私が見つけた最良の解決策です。

それが役立つことを願っています。

于 2010-09-19T04:49:34.660 に答える
0

質問の言い方からすると、スレッドがどのように機能するのかよくわからないようです。「スレッドが別のスレッドに移動する前に実行できる時間」とは、スレッドごとに費やされる CPU サイクルの数を意味すると思います。これは毎秒数十万回発生します。

Boost.Thread はスレッドの優先度をサポートしていませんが、OS 固有のスレッド API はサポートしています。ただし、あなたの問題は、根本的な再設計、または少なくともボトルネックを見つけるための重いプロファイリングの必要性を示しているようです。

于 2010-09-19T00:07:24.683 に答える