问题标签 [readerwriterlockslim]

我正在使用 ReaderWriterLockSlim 来保护对 ASP.NET 应用程序上缓存的访问。MSDN 有使用锁的例子。然而这篇文章http://www.nobletech.co.uk/Articles/ReaderWriterLockMgr.aspx让我担心死锁。这真的有风险吗？MSDN 文档应该提到这一点吗？

Joe Duffy 关于ReaderWriterLockSlim的文章并没有让我充满信心！

在 Orcas 中引入新的 ReaderWriterLockSlim

锁对异步异常（例如线程中止和内存不足）不可靠。如果其中一种发生在锁定方法之一的中间，则锁定状态可能会损坏，从而导致随后的死锁、未处理的异常，并且（可悲的是）由于内部使用自旋锁而导致 100% 的 CPU 挂钩。

如何在 ASP.NET 中安全地使用 ReaderWriterLockSlim？

所以我的理解是，在 ReaderWriterLock（或者更具体地说是 ReaderWriterLockSlim）上，读取和写入都需要获取互斥锁来获取锁。我想优化锁的读取访问，这样如果没有挂起的写入，就不需要获取锁。（而且我愿意牺牲写入的性能，对读取添加一些约束，使第一次读取慢，第二次读取快等等。如果有必要，只要绝大多数读取尽可能快。 )

那么，如何做到这一点，或者更好的是，是否有一个框架或“标准”实现可以指向我？（或者如果我误解了它已经被支持了，太好了！）

所以对于我的文章：似乎如果有一个读者/作者数量的计数器（受 Interlocked.Increment 保护），这足以让读者检查作者计数是否非零，并且然后才获取锁。（如果获得，则在锁内递增。）

编写器总是递增、获取锁、旋转直到读者计数变为 0（愿意假设读者总是快速完成，甚至在乐观的情况下完全绕过读者计数），最后递减。（当我们阻塞时，也可以设置某种形式的优先级，或者可能一次性清除所有待处理的读取器/写入器，因为我只保护一个值，但我现在会放弃它......）

所以..有人见过类似的东西或有什么建议吗？如果一段时间后没有任何内容，我很乐意将初始实现放在一起并更具体地进行讨论。

In writing some threaded code, I've been using the ReaderWriterLockSlim class to handle synchronized access to variables. Doing this, I noticed I was always writing try-finally blocks, the same for each method and property.

Seeing an opportunity to avoid repeating myself and encapsulate this behaviour I built a class, ReaderWriterLockSection, intended to be used as a thin wrapper to the lock which can be used with the C# using block syntax.

The class is mostly as follows:

I use the section as follows:

To me, this seems like a good idea, one that makes my code easier to read and seemingly more robust since I wont ever forget to release a lock.

Can anybody see an issue with this approach? Is there any reason this is a bad idea?

我正在开发一个用作缓存的线程安全类，它应该可以在 .NET 和 Mono 中工作。

项目有生存时间，每次检索对象时，都会刷新其生存时间。每次我添加一个项目时，时间戳都会添加到另一个拥有相同键的集合中。计时器引发了查找过时项目并将其删除的方法。

当我尝试获取和项目时，我还必须提供一个委托，指示如果缓存中不存在它如何获取它。

我已经进行了测试，虽然在测试中应该每 30 秒删除一次项目，但它经常发生，几乎每秒发生一次，我不知道为什么。

这是课程：

如您所见，在调试模式下，添加项目时会打印“_”符号，删除项目时会打印“-”符号。在测试中，第二分钟后可以看到项目是如何在同一秒内被删除和添加的，此时项目应该每 30 秒才被删除一次，我不知道为什么：

这就是我测试的方式：

您在 GenericCache 类中看到任何问题吗？

在此先感谢，亲切的问候。

所以我有一种情况，我可能有很多次读取，并且偶尔会写入多个线程之间共享的资源。

很久以前，我读到了ReaderWriterLock，并且已经读到了ReaderWriterGate哪些尝试来缓解许多写入胜过读取并损害性能的问题。然而，现在我已经意识到ReaderWriterLockSlim...

从文档中，我相信任何时候都只能有一个线程处于“可升级模式”。在我使用的唯一访问权限是EnterUpgradeableReadLock()（这适合我的场景）的情况下，那么坚持使用有很大的不同lock(){}吗？

这是摘录：

如果已经有线程处于可升级模式，如果有线程等待进入写入模式，或者如果有单个线程处于写入模式，则尝试进入可升级模式的线程会阻塞。

或者，递归策略对此有何影响？

我有一个包含项目集合的对象。我希望能够通过 AddItem 方法将项目添加到集合中，并且还希望能够浏览集合中的所有项目。我的对象必须是线程安全的。我正在使用 ReaderWriterLockSlim 来确保正确同步。我应该如何同步 GoThroughAllItems 方法？我应该在整个持续时间（可能很长）中启动一个大的 ReadLock，还是应该为从集合中获取的每个项目释放锁，并为下一个重新获取锁？

这是一些示例代码：

当 GC.Collect 在具有 ReaderWriterLockSlim 成员变量的类上执行时，我有一段示例代码说明了我的代码中的问题。GC.Collect 需要 2 到 3 秒来运行。我需要定期执行 GC，因为我的应用程序非常占用内存。

有没有人遇到过类似的问题？

谢谢伊恩

我喜欢 C# 中的快捷方式lock(myLock){ /* do stuff */}。读/写锁是否有等价物？（特别是 ReaderWriterLockSlim。）现在，我使用以下自定义方法，我认为它有效，但有点烦人，因为我必须将我的操作作为匿名函数传递，并且如果可能，我更愿意使用标准锁定机制.

我有一些代码必须是线程安全的，其行为类似于：

计算必须同时锁定值和计数器，否则竞争条件可能会影响 if(...) 块，但是它们在被读出时根本不需要同步，即如果计数器和值在尝试阅读两者，这对我来说是 100% 好的。

读取时的互锁用于 64 位值的线程安全读取。

1. 像这样混合联锁和锁安全吗？我在其他网页上读到混合它们是不安全的，但是如果这意味着混合它们是引入细微错误的好方法，或者如果在系统级别这会破坏所涉及的数据结构，我无法找到澄清。

2. 所有这些互锁（64 位 .NET 4.0 运行时）的成本是否完全违背了在属性 get() 方法周围保存 ReaderWriterSlim 锁的目的？