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

MSDN 文档 http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx以及许多使用的例子ReaderWriterLockSlim类建议使用以下模式：

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

但我很好奇它是否完全安全。是否有可能在获取锁之后、锁之前发生一些异常？try语句使锁卡在锁定状态？最明显的候选人是ThreadAbortException。我知道这种情况发生的概率极小，但后果却极坏，所以我觉得值得考虑一下。我不相信编译器理解这种模式并阻止处理器之前中断线程try陈述。

如果理论上有可能该代码不安全，是否有方法使其更安全？

我能想到的理论上只有三种方法可能会失败：

• ThreadAbortException你已经提到过。这很容易正确处理：只要确保你从不打电话Thread.Abort()。你几乎肯定不需要；几乎总是有更好的方法来达到预期的结果。

  Only if you 真的，真的，真的需要调用它，and您要中止的线程是有保持锁打开风险的线程，请将您的整个代码块（从Enter to Exit) in a try...finallytry 块为空的子句。Thread.Abort()会抛出ThreadAbortException仅当当前finally处理程序完成。

• StackOverflowException是另一种可能性。这可能发生在通话过程中ExitWriteLock。这也相当简单：当发生堆栈溢出时，进程就会终止。你无法抓住或处理这个问题。由于进程已终止，进程中的其他线程将不会保持任何锁定打开状态。

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

简而言之，我不会担心。