Tag: readerwriterlockslim

使用ReaderWriterLock的真正缺点是什么？: 我们有项目针对.NET 2.0 RTM（是的，它应该是.NET 2.0 RTM，我们有一些正统的客户端）。而我只是想知道ReaderWriterLock的缺点是什么？为什么每个人都说“不要使用它，尝试使用lock语句之类的东西”这么糟糕？如果我们可以使用.NET 3.5，我肯定会使用ReaderWriterLockSlim ，但是对于ReaderWriterLock我对来自各地的所有这些警告感到有点害怕。有人测量过表现还是其他什么？如果存在一些性能问题，我们可以在哪些有效负载下遇到它们？我们在ReaderWriterLock主要目的方面有一个经典的情况，即多次读取和很少写入。使用lock语句会阻止所有读者。也许对我们来说这不是一个可怕的问题，但如果我能使用ReaderWriterLock我会更满意。 IMO介绍几台显示器确实是一个非常糟糕的主意。

ReaderWriterLockSlim.EnterUpgradeableReadLock（）与Monitor.Enter（）基本相同吗？: 所以我的情况是，我可能有很多次读取，只偶尔写入多个线程之间共享的资源。很久以前我读过有关ReaderWriterLock ，并且已经阅读了有关ReaderWriterGate ，该内容试图缓解许多写入特朗普的内容并损害性能的问题。但是，现在我已经意识到ReaderWriterLockSlim …… 从文档中，我相信在任何时候都只能有一个“可升级模式”的线程。在我使用的唯一访问是EnterUpgradeableReadLock() （适用于我的场景）的情况下，那么只是坚持使用lock(){}会有很大的不同吗？这是摘录：如果已有线程处于可升级模式，有线程等待进入写入模式，或者如果写入模式中存在单个线程，则尝试进入可升级模式的线程会阻塞。或者，递归策略对此有何影响？

ReaderWriterLockSlim是正确的选择吗？: 我正在为在Windows Azure中运行的应用程序编写全局error handling程序/记录器。当应用程序中发生错误时，执行需要以primefaces方式执行的许多操作。我需要防止在上一个错误完成之前记录错误。同时，我希望根据需要读取日志。我最初的想法是使用Monitor / lock并仅锁定错误写入。这样就完全没有抑制读取。我想知道ReaderWriterLockSlim是否更合适。我不能说我真正理解一种方法与另一种方法之间的价值。我应该创建一个ReaderWriterLockSlim并执行以下操作（将读取包装在EnterReadLock中）… public static void LogError(Exception exception) { _lock.EnterWriteLock(); … _lock.ExitWriteLock(); } 或者我只是执行以下操作，只锁定写入部分： public static void LogError(Exception exception) { lock (someStaticLock) { … } } 任何想法/建议将不胜感激。

ReaderWriterLockSlim.EnterUpgradeableReadLock（）始终是死锁？: 我对ReaderWriterLockSlim非常熟悉，但我最近尝试在类中实现了EnterUpgradeableReadLock() …很快我意识到当2个或更multithreading运行代码时，这几乎肯定是一个保证死锁： Thread A –> enter upgradeable read lock Thread B –> enter upgradeable read lock Thread A –> tries to enter write lock, blocks for B to leave read Thread B –> tries to enter write lock, blocks for A to leave read Thread A –> waiting for B to exit read lock Thread […]