根据语言规范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);
}
这似乎比必要复杂得多。所以问题是,该实施的优势是什么?
答案 0 :(得分:5)
一如既往,Eric Lippert已经回答了这个问题:
Fabulous Adventures In Coding: Locks and exceptions do not mix
答案 1 :(得分:2)
最近我在“CLR via C#”中读到它可能实际上并不是一个优势。原因是finally
块始终释放锁定的资源,即使try
块因意外错误而退出。这可能会使资源处于未定义状态并且可以访问。该程序不会死锁,但错误可能会更加微妙,因此更难找到。
这当然取决于具体情况,但我想当前的lock
实现最有意义的是,如果您的优先级是防止因最坏情况下线程意外中断而导致的死锁。