C# 4.0“修复了”死锁问题

C# 4.0“修复了”死锁问题

几年前，Eric Lippert注意到根据同样源代码进行优化构建和非优化构建会导致不同的潜在死锁。这个问题会在C# 4.0中被“修复”。“修复”放在引号当中，是因为解决方式也有它自己的问题。

最初的问题可能来自于编译器在把IL转化为机器代码的时候，根据你是否打开或关闭优化器和调试器，以非一致的行为插入了no-op指令。Lippert提道：

回想一下，lock(obj){body}实际上就是下面代码的语法：

var temp = obj;
Monitor.Enter(temp);
try { body }
finally { Monitor.Exit(temp); }

这里的问题是，如果编译器在Monitor.Enter和受try保护的区域之间生成了no-op指令，那么运行时就有可能 在Monitor.Enter之后和try之前抛出线程终止异常。在这样的情形下，finally不会执行，那么也就产生了程序锁泄漏，程序有可能出现死 锁。如果在非优化和优化构建中不存在差异，就不存在这个问题。

不过。这个解决方案[译注：C# 4.0是将Monitor.Enter()移入到try子句中，并在Enter的时候会传递一个引用值，标识锁是否被占用。在finnally子句中，会 首先判断锁是否被占用，如果被占用，则释放锁。]也有它自己的问题。据Eric说，“保持一致与不一致相比，完全就是五十步笑百步。它仍然存在很大的问 题...这样生成的代码所[译注：生成的代码是指编译器将lock转换为IL，实际上就相当于使用Monitor的语法]隐含的意义就是认为死锁程序是可 能 发生的最糟糕的事情。这种说法未必准确。”

锁的目的是为了保护可变资源，或者换句话说，是为了避免可变资源的多个潜在用户访问资源已被破坏的版本。4.0版本的现有解决方案并没有包含回滚到 原始状态的功能，也没有保证可变资源的完整性。强行进入lock语句的finally子句、释放锁以及允许访问任意等待 线程（该线程占用了已被破坏的资源），都有可能引发异常。这一解决方案在结果的一致性、降低死锁的可能性和对访问被破坏状态可能付出的代价方面，做出了折 衷。该问题尤其在多线程编程中会存在风险。

这个特定的折衷是对两种糟糕结果的选择：程序死锁，还是不再保护重要资源的状态。所谓“两害相权取其轻”，当我们进行多线程编程时，就必须在多个设计决策与权衡中做出一个选择。

这篇文章反响热烈， 一些开发人员认为这类设计问题不只限于多线程，在“安全锁”和“安全异常”之间也存在不同之处。Lippert也同意多线程只会让难处理的问题更难，“正 确获得锁仅仅是万里长征的第一步”，你的设计还需要考虑其他各种异常，以及在异常发生后如何处理它们。大量的回复者指出终止线程的危险性，并部分同意 Lippert所说的“终止异常纯粹就是找死”。