问题描述
所以我遇到这样的情况，我可能有很多次读取，而只是偶尔写入多个线程之间共享的资源.
So I have a situation where I may have many, many reads and only the occasional write to a resource shared between multiple threads.
很久以前，我阅读了有关ReaderWriterLock的文章，并了解了有关 ReaderWriterGate 试图缓解许多读取进入王牌读取并损害性能的问题.但是，现在我已经意识到 ReaderWriterLockSlim ...
A long time ago I read about ReaderWriterLock, and have read about ReaderWriterGate which attempts to mitigate the issue where many writes coming in trump reads and hurt performance. However, now I've become aware of ReaderWriterLockSlim...
从文档中，我相信任何时候都只能有一个线程处于可升级模式".在我正在使用的唯一访问权限是 EnterUpgradeableReadLock() (适合我的情况)，那么坚持使用lock(){}有什么区别?
From the docs, I believe that there can only be one thread in "upgradeable mode" at any one time. In a situation where the only access I'm using is EnterUpgradeableReadLock() (which is appropriate for my scenario) then is there much difference to just sticking with lock(){}?
这是摘录:
或者，递归策略对此有什么影响吗?
Or, does the recursion policy make any difference to this?
推荐答案
同意.如果您所有线程的所有需要获取可升级的读取锁 ，而您无力释放读取锁并获得写入锁，则ReaderWriterLockSlim对简单的排他锁没有任何改进. .递归不会改变这一点. RWLS以及避免出现永远存在的死锁危险的需求在很大程度上支持一种由单个线程进行写操作的模式.
Agreed. If all of your threads need to acquire an upgradable read lock and you cannot afford to release a read lock and acquire a write lock then ReaderWriterLockSlim is no improvement over a simple exclusive lock. Recursion does not change that. RWLS and the need to avoid the ever present danger of deadlock heavily favors a pattern where a single thread does the writing.
这篇关于ReaderWriterLockSlim.EnterUpgradeableReadLock()与Monitor.Enter()是否基本相同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！