ReaderWriterLockSlim：可升级锁后获取读锁不会抛出 LockRecursionException答案

【问题标题】：ReaderWriterLockSlim: acquiring a read lock after an upgradeable lock doesn't throw LockRecursionExceptionReaderWriterLockSlim：可升级锁后获取读锁不会抛出 LockRecursionException
【发布时间】：2013-02-11 11:56:38
【问题描述】：

关于ReaderWriterLockSlim：

随后在同一个线程中获取两个锁实际上应该抛出LockRecursionException（递归策略设置为NoRecursion）。

我的观察结果：

reader 锁，然后 reader 锁 --> LockRecursionException
reader 锁，然后 upgradeable reader 锁 --> LockRecursionException
reader 锁，然后 writer 锁 --> LockRecursionException
可升级读卡器锁，然后读卡器锁 --> 无异常
可升级读卡器锁，然后是可升级读卡器锁 --> LockRecursionException
可升级阅读器锁，然后写入器锁 --> 无异常
writer 锁，然后 reader 锁 --> LockRecursionException
writer 锁，然后 upgradeable reader 锁 --> LockRecursionException
writer 锁，然后 writer 锁 --> LockRecursionException

这种行为正确吗？

【问题讨论】：

标签： .net multithreading concurrency synchronization

【解决方案1】：

From the docs:

可升级模式的线程可以通过首先调用EnterReadLock 方法然后调用ExitUpgradeableReadLock 方法来降级到读取模式。所有锁递归策略都允许这种降级模式，即使是NoRecursion。

我的理解是，对于写入的情况，进入写入锁是无论如何从可升级模式转变为写入模式的正常方式，因此即使在NoRecursion的策略下也必须得到支持（不可升级的可升级锁似乎没有什么意义:)

【讨论】：

是的，这也是我的理解。这两条路径是正常的升级和降级方案。因此，无论递归策略如何，都必须允许它们。我的困惑至少部分源于我从未将其视为可降级锁......
@JohnSloper 不，我也没有意识到它可以降级。不过，如果一个线程可以确定它不再需要写入，则很方便。