MSDN Documentation许多使用 ReaderWriterLockSlim
类的示例建议使用以下模式:
cacheLock.EnterWriteLock();
try
{
//Do something
}
finally
{
cacheLock.ExitWriteLock();
}
但我很好奇它是否完全安全。有没有可能在获取到lock之后,try
语句之前发生异常,导致lock卡在locked状态?最明显的候选者是 ThreadAbortException
。我明白这种情况发生的概率极小,但后果却极差——所以我觉得还是值得考虑一下。我不相信编译器理解这种模式并阻止处理器在 try
语句之前中断线程。
如果从理论上讲这段代码可能不安全,是否有办法让它更安全?
最佳答案
我能想到的理论上只有三种失败方式:
ThreadAbortException
您已经提到了。这很容易正确处理:只需确保您永远不会调用Thread.Abort()
。你几乎肯定不需要;几乎总有更好的方法可以达到预期的结果。只有当您真的、真的、真的需要调用它时,并且您要中止的线程是有风险的线程要保持锁打开,请将整个代码块(从
Enter
到Exit
)放在try
...finally
try block 为空的子句。Thread.Abort()
将仅在当前finally
处理程序完成时抛出ThreadAbortException
。StackOverflowException
是另一种可能性。它可能在调用ExitWriteLock
期间发生。这也相当简单:当堆栈溢出发生时,进程终止。你无法捕获或处理这个。由于该进程已终止,您进程中的任何其他线程都不会保持任何锁打开状态。OutOfMemoryException
理论上可能会在调用ExitWriteLock
期间抛出。与StackOverflowException
不同,这个异常在理论上是可以捕获的。如果您没有捕获它,该进程将再次终止,并且您进程中的其他线程将不会保持任何锁打开状态。但是,如果您确实捕获了它,您就不能指望正确地处理它,而且您的其他线程很可能很快也会开始抛出此异常。
简而言之,我不会担心。
关于c# - 使用带有后续 try-finally 子句的 ReaderWriterLockSlim.EnterXXX() 模式是否完全安全,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24533104/