ac＃スレッドアプリで、オブジェクトをロックする場合、キューとしましょう。例外が発生した場合、オブジェクトはロックされたままになりますか？疑似コードは次のとおりです。
int ii;
lock(MyQueue)
{
MyClass LclClass = (MyClass)MyQueue.Dequeue();
try
{
ii = int.parse(LclClass.SomeString);
}
catch
{
MessageBox.Show("Error parsing string");
}
}
私が理解しているように、catchの後のコードは実行されませんが、ロックが解放されるかどうか疑問に思っていました。
回答:
最初; TryParseを検討しましたか？
in li;
if(int.TryParse(LclClass.SomeString, out li)) {
// li is now assigned
} else {
// input string is dodgy
}
ロックは2つの理由で解放されます。まず、lock本質的には：
Monitor.Enter(lockObj);
try {
// ...
} finally {
Monitor.Exit(lockObj);
}
第二に; 内部例外をキャッチして再スローしないため、lock実際に例外が発生することはありません。もちろん、MessageBoxの期間中はロックを保持しているため、問題が発生する可能性があります。
したがって、最も致命的な壊滅的な回復不能な例外を除いて、すべてリリースされます。
この古い質問への回答の中で、例外時にロックを解除することは非常に危険なことであると誰も言及していないことに注意してください。はい、C＃のロックステートメントには「最終的に」セマンティクスがあります。コントロールが正常または異常にロックを終了すると、ロックが解除されます。皆さんはこれについて良いことのように話しているのですが、悪いことです！未処理の例外をスローするロックされた領域がある場合の正しい方法は、ロックを解除して続行するのではなく、より多くのユーザーデータを破棄する直前に、問題のあるプロセスを終了することです。
このように見てください。ドアに鍵がかかったバスルームと、外で待っている人々の列があるとします。トイレの爆弾が爆発し、そこにいる人が死亡した。あなたの質問は、「その状況では、次の人がトイレに入ることができるように、ロックが自動的にロック解除されますか？」です。はい、そうなります。 それは良いことではありません。爆弾が爆発し、誰かを殺しました！配管はおそらく破壊されており、家はもはや構造的に健全ではなく、そこに別の爆弾がある可能性があります。正しいことは、全員をできるだけ早く外に出し、家全体を取り壊すことです。
つまり、考えてみてください。別のスレッドで変更せずにデータ構造から読み取るためにコードの領域をロックし、そのデータ構造内の何かが例外をスローした場合、それはデータ構造が原因である可能性が高いです。破損しています。ユーザーデータがめちゃくちゃになりました。破損したデータを保存するため、この時点ではユーザーデータの保存を試みたくありません。プロセスを終了するだけです。
別のスレッドが同時に状態を読み取らずにミューテーションを実行するためにコードの領域をロックし、ミューテーションがスローされた場合、データが以前に破損していなければ、確実に破損します。これはまさに、ロックが保護することになっているシナリオです。これで、その状態の読み取りを待機しているコードは、すぐに破損状態へのアクセスを許可され、おそらくそれ自体がクラッシュします。繰り返しますが、正しいことはプロセスを終了することです。
どのようにスライスしても、ロック内の例外は悪いニュースです。正しい質問は、「例外が発生した場合にロックがクリーンアップされるか」ではありません。正しい質問は、「ロック内で例外が発生しないようにするにはどうすればよいですか。例外がある場合は、ミューテーションが以前の良好な状態にロールバックされるようにプログラムを構成するにはどうすればよいですか？」です。
はい、それは適切にリリースされます。最終的には/lockとして機能するため、どのように終了しても解放されます。補足として、;のスタックトレースに損傷を与えるため、避けるのが最善です。それはそれをキャッチし、より良いではない、すべての使用を：、または代替としてではなく再スローをしています。tryfinallyMonitor.Exit(myLock)catch(... e) {throw e;}ethrow;throw e;
本当に知りたい場合は、C＃4 / .NET4のロックは次のとおりです。
{
bool haveLock = false;
try {
Monitor.Enter(myLock, ref haveLock);
} finally {
if(haveLock) Monitor.Exit(myLock);
}
}
「lockステートメントは、Monitor.Enterの呼び出しにコンパイルされ、次にtry…finallyブロックにコンパイルされます。finallyブロックでは、Monitor.Exitが呼び出されます。
x86とx64の両方のJITコード生成により、Monitor.Enter呼び出しとその直後のtryブロックの間でスレッドアボートが発生しないことが保証されます。」
取得元： このサイト
Monitor.Enterとの間にNOPを挿入するtryため、の「直後に従う」条件JITに違反しています。
ロックが正しく解除されます。Alockは次のように動作します。
try {
Monitor.Enter(myLock);
// ...
} finally {
Monitor.Exit(myLock);
}
また、finallyブロックをどのように離れても、tryブロックは実行されることが保証されています。
マークの優れた答えに少しだけ追加します。
このような状況こそが、lockキーワードが存在する理由です。これは、開発者がfinallyブロック内でロックが解除されていることを確認するのに役立ちます。
タイムアウトをサポートするためにMonitor.Enter/を使用Exitする必要がある場合は、例外が発生した場合にロックが適切に解放されるようMonitor.Exitに、必ずfinallyブロック内にを呼び出す必要があります。