1

次の擬似を観察します。

ManualResetEvent[] resetEvents = new ManualResetEvent[operations.Count];

for( int i = 0; i < operations.Count; i++ )
{
  resetEvents[i] = new ManualResetEvent(false);
  ThreadPool.QueueUserWorkItem(new WaitCallback(timeConsumingOpHandler), resetEvents[i]);
}

WaitHandle.WaitAll(resetEvents);

プールされたスレッドのいずれかで例外が発生した場合、ASP.NET WebApp はデッドロック状態になります。応答ストリームで渡される例外情報はありません。これを防ぐための提案を求めています。固定のタイムアウトは許容されます。timeConsumingOpHandler が WaitHandle を Set() するとします。

timeConsumingOpHandler 全体が try-catch-finally ブロックにラップされ、finally セクションで WaitHandle が Set() になります。それでも、デッドロックが発生します。

4

3 に答える 3

1

デッドロックに陥っていると確信していますか? .NET 2.0 では、処理されない例外ThreadPool はプロセスを終了します。

ThreadPoolASP.NET アプリケーションでは を使用しないでください。ASP.NET 自体は を使用しThreadPoolて要求を処理するため、同じセットのスレッドを競合しています。非同期実行が必要な場合は、非同期デリゲートを使用します。

于 2009-02-20T12:43:29.300 に答える
0

自動デッドロック検出を提供するためにJoeDuffyが開発したMSDNのカスタムCLRホストを確認することをお勧めします。

于 2009-02-20T15:37:41.177 に答える
0

ブロッキング操作は、デッドロックの可能性があります。デッドロックが発生する可能性を最小限に抑える、または実質的に排除する方法はいくつかありますが (同期操作が有限時間内に終了することを常に確認する場合)、一般的なケースでは、安全な方法があると仮定することはできません。デッドロックを防ぎます。

タイムアウトは、アプリケーションがデッドロックしないようにするのに大いに役立ちますが、停止すると例外的な方法でタイムアウトから回復する必要があります。同じプログラム フローは適用されなくなりました。

例外をスローするスレッドがある場合、Visual Studio の [デバッグ] > [出力] ウィンドウを確認すると、複数のスレッドを処理するときにデバッガーがブレークに失敗しても、常に例外がキャッチされるようです。

並列処理を実現するために、作業を別々のスレッドに分割しているようです。ASP.NET アプリケーションでこれが必要なのはなぜですか?

于 2009-02-20T06:35:43.987 に答える