5

言語仕様によると、次のlock(obj) statement;ようにコンパイルされます。

object lockObj = obj; // (the langspec doesn't mention this var, but it wouldn't be safe without it)
Monitor.Enter(lockObj);
try
{
    statement;
}
finally
{
    Monitor.Exit(lockObj);
}

ただし、次のようにコンパイルされます。

try
{
    object lockObj = obj;
    bool lockTaken = false;
    Monitor.Enter(lockObj, ref lockTaken);
    statement;
}
finally
{
    if (lockTaken) Monitor.Exit(lockObj);
}

それは必要以上に複雑なようです。問題は、その実装の利点は何ですか?

4

2 に答える 2

5

いつものように、Eric Lippert はすでにこれに答えています。

コーディングのすばらしい冒険: ロックと例外は混在しない

于 2012-06-07T15:46:13.460 に答える
2

最近、「C# 経由の CLR」を読みましたが、実際には利点ではないかもしれません。その理由は、予期しないエラーの結果としてブロックが終了したfinally場合でも、ブロックは常にロックされたリソースを解放するためです。tryこれにより、リソースが未定義の状態になり、アクセス可能になる可能性があります。プログラムがデッドロックすることはありませんが、エラーははるかにわかりにくく、見つけにくい場合があります。

それは確かに状況に依存しlockますが、可能な限り最悪の場所でスレッドの予期しない中断によるデッドロックを防ぐことが優先される場合、現在の の実装が最も理にかなっていると思います。

于 2012-06-30T22:21:33.300 に答える