パフォーマンスプロファイリングの目的で、WaitHandle.SignalAndWaitの呼び出しを無視できますか？

Question

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

ANTSや一般的なパフォーマンスプロファイリングにはまったく慣れていません（つまり、私は非常に粗悪で、ぼやけていると確信しているセルフプロファイリングを除いて、double timeToComplete = (endTime - startTime).TotalSecondsなど）。アプリケーションとそれがどのように使用されているかを理解することができます。しかし、私は問題のコードを担当する開発者に電話し、彼の即時の反応は "うん、それはそれを言うことを私には驚かないが、そのコードはSignalAndWait [ANTSのおかげで私が見ることができた] CPUを使用せず、何かを待っているだけです」彼は私に、単にそのコードを無視し、私が見つけることができる何かを探すように勧めました。

私の質問：SignalAndWaitはCPUオーバーヘッドを必要としません（もしそうなら、これはどのように可能ですか）。そして、パフォーマンスプロファイラが99％のCPU時間を費やしていると考えるのは妥当でしょうか？特に興味があるのは、それが99％であれば、アプリケーションが頻繁にアイドルであることを示唆しているからです。しかし、そのパフォーマンスは最近遅れている。

私が言ったように、私は実際にはこのツールについては初心者であり、WaitHandleクラスについては何も知らない。だから私はここで何が起こっているのか理解するのに役立つ情報は感謝します。

Answer 1

WaitHandleは本当にスレッドをスリープ状態にします。

これらのハンドルのタイムアウトを設定して、一定期間後にスリープ解除できるようにすることが追加されました。

また、別のスレッド（たとえば、アプリケーション終了など）からWaitHandleを通知して、すぐにWakeUpすることもできます。

は私が個人的に同じタイムアウト付きのThread.sleep上でショートタイムアウトとWaitHandleを好む、睡眠が必要な場合WaitHandleがすぐに再開することができる一方で、それはリターンあなたは、操作を再開することができなければならない前に開始されたときのように。

Answer 2

コードに深刻なバグがある可能性があります。 EventWaitHandleには、リセットモードによって2つのセマンティクスがあります。 EventWaitHandleがAutoResetモードの場合、待機中のすべてのスレッドは、イベントが通知されるまでブロックされます。イベントがシグナルになると、それ以降の待機操作はその状態をリセットし、スレッド呼び出し待機ブロックを再度リセットします。

しかし、EventWaitHandleがManualResetモードの場合、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); 
} 

上記のループは、いくつかの他のスレッドまで、あなたのCPUのほとんどを食べるようになる。このhyphotheticalシナリオを検討していないSignalAndWaitブロックを行いますされ、h1.Reset（）を呼び出します。

これが役に立ちます。

詳細については、 http://msdn.microsoft.com/en-us/library/system.threading.eventwaithandle.aspx