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，这个理论上是可以捕获的。如果您没有捕获它，该进程将再次终止，并且进程中的任何其他线程都不会保持任何锁定打开状态。但是，如果您确实捕获了它，则不能指望正确处理此异常，并且很可能您的其他线程也将很快开始抛出此异常。
简而言之，我不会担心。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
