3

Red Gate から ANTS Performance Profilerの試用版をダウンロードし、チームのコードの一部を調査しています。すぐに、ANTS が最大 99% の CPU 時間を消費していると報告しているコードの特定のセクションがあることに気付きました。

私はANTSや一般的なパフォーマンスプロファイリングに完全に慣れていません（つまり、 のような非常に粗雑で眉をひそめている方法であると確信しているものを使用した自己プロファイリングは別としてdouble timeToComplete = (endTime - startTime).TotalSeconds）、まだアプリケーションをいじって考えていますそれがどのように使用されているかを示します。しかし、問題のコードの責任者である開発者に電話をかけたところ、彼の反応はすぐに次のようになりました。は CPU をまったく使用せず、何かが行われるのを待っているだけです。」彼は、単にそのコードを無視して、他に見つけられるものを探すようにアドバイスしてくれました。

私の質問: SignalAndWait が CPU オーバーヘッドを必要としないというのは本当ですか (もしそうなら、これはどのように可能でしょうか?)、そしてパフォーマンス プロファイラーがそれを 99% の CPU 時間を占有していると見なすのは合理的ですか? これが特に興味深いのは、99% の場合、アプリケーションが頻繁にアイドル状態になっていることを示しているからです。それでも、最近はそのパフォーマンスがかなり鈍くなっています。

私が言ったように、私はこのツールに関しては本当に初心者であり、WaitHandle クラスについては何も知りません。したがって、ここで何が起こっているのかを理解するのに役立つ情報があれば幸いです。

4

2 に答える 2

1

WaitHandleは、実際にスレッドをスリープ状態にします。

追加のボーナスは、これらのハンドルにタイムアウトを設定して、一定期間後にウェイクアップできるようにすることです。

別のスレッド（アプリケーションの終了など）からWaitHandleにシグナルを送信すると、すぐにウェイクアップすることもできます。

私は個人的に、スレッドよりもタイムアウトが短いWaitHandleを好みます。同じタイムアウトのSleepは、Sleepが開始されると、操作を再開する前に戻る必要がありますが、WaitHandleは必要に応じてすぐに再開できます。

于 2009-06-24T00:13:50.080 に答える
0

コードに重大なバグがあるのではないかと思います。EventWaitHandleには、リセットモードに応じて2つのセマンティクスがあります。EventWaitHandleがAutoResetモードの場合、イベントが通知されるまですべての待機中のスレッドがブロックされます。イベントが通知されると、その後の待機操作によって状態がリセットされ、スレッドが待機ブロックを再度呼び出します。

ただし、EventWaitHandleがManualResetモードの場合、Reset Manualを呼び出すまで通知されたままになります。つまり、EventWaitHandleが通知され、スレッドがタイトループで待機を呼び出している場合、このスレッドはリセットされるまでブロックされません。イベントで手動で呼び出されるため、この架空のシナリオを検討してください

EventWaitHandle h1, h2;
h1 = new EventWaitHandle(true, EventWaitHandle.ManualReset); // the event is already signaled.
h2 = new EventWaitHandle(false, EventWaitHandle.ManualReset);
while(true)
{
  WaitHandle.SignalAndWait(h2,h1);
}

上記のループは、他のスレッドがh1.Reset（）を呼び出すまで、CPUの大部分を消費します。これにより、SignalAndWaitブロックが作成されます。

お役に立てれば。

詳細については、 http：//msdn.microsoft.com/en-us/library/system.threading.eventwaithandle.aspxを確認してください。

于 2009-06-24T05:24:22.837 に答える