c# - 使用带有后续 try-finally 子句的 ReaderWriterLockSlim.EnterXXX() 模式是否完全安全

Question

MSDN Documentation许多使用 ReaderWriterLockSlim 类的示例建议使用以下模式:

cacheLock.EnterWriteLock();
try
{
    //Do something
}
finally
{
    cacheLock.ExitWriteLock();
}

但我很好奇它是否完全安全。有没有可能在获取到lock之后，try语句之前发生异常，导致lock卡在locked状态？最明显的候选者是 ThreadAbortException。我明白这种情况发生的概率极小，但后果却极差——所以我觉得还是值得考虑一下。我不相信编译器理解这种模式并阻止处理器在 try 语句之前中断线程。

如果从理论上讲这段代码可能不安全，是否有办法让它更安全？

Answer 1

我能想到的理论上只有三种失败方式:

• ThreadAbortException 您已经提到了。这很容易正确处理:只需确保您永远不会调用 Thread.Abort()。你几乎肯定不需要；几乎总有更好的方法可以达到预期的结果。

  只有当您真的、真的、真的需要调用它时，并且您要中止的线程是有风险的线程要保持锁打开，请将整个代码块(从 Enter 到 Exit)放在 try...finally try block 为空的子句。 Thread.Abort() 将仅在当前 finally 处理程序完成时抛出 ThreadAbortException。

• StackOverflowException 是另一种可能性。它可能在调用 ExitWriteLock 期间发生。这也相当简单:当堆栈溢出发生时，进程终止。你无法捕获或处理这个。由于该进程已终止，您进程中的任何其他线程都不会保持任何锁打开状态。

• OutOfMemoryException 理论上可能会在调用 ExitWriteLock 期间抛出。与 StackOverflowException 不同，这个异常在理论上是可以捕获的。如果您没有捕获它，该进程将再次终止，并且您进程中的其他线程将不会保持任何锁打开状态。但是，如果您确实捕获了它，您就不能指望正确地处理它，而且您的其他线程很可能很快也会开始抛出此异常。

简而言之，我不会担心。