问题标签 [readerwriterlock]

我最近遇到了多线程性能问题，并开始研究如何优化当前代码。

最适合我的问题的解决方案是使用读写锁，但是 Jeffrey Richter 的这篇文章让我对使用这种锁产生了一些疑问。我的读者比作者多得多，但是应该尽快应用作者的更改。

这种行为是否仍然存在于 .net 4.5 版本的读写器锁中？我的意思是读线程优先于写线程？

我想在这个函数中使用 ReaderWriterLock：

该函数每秒调用 30 次，每次将数据写入文本文件。我想添加代码来锁定函数，直到每次完成写入采样数据。我需要添加哪些代码才能在 vs2013 c# xaml 上运行良好？

下面是一个多读/写共享数据的尝试，它使用 std::atomics 和忙等待而不是互斥锁和条件变量来在读写器之间同步。我很困惑为什么那里的断言被击中。我确定逻辑中的某个地方存在错误，但我不确定它在哪里。

实现背后的想法是，读取的线程一直在旋转，直到写入器完成写入。当他们进入读取函数时，他们会增加 m_numReaders 计数，而当他们等待写入者时，他们会增加 m_numWaiting 计数。

这个想法是，如果 m_numWaiting 总是在 m_numReaders 之后递增并在 m_numReaders 之前递减，则 m_numWaiting 应该总是小于或等于 m_numReaders。

不应该出现 m_numWaiting 大于 m_numReaders （或者我没有看到）的情况，因为读取器总是首先增加读取器计数器，并且有时只会增加等待计数器，而等待计数器总是首先减少。

然而，这似乎是正在发生的事情，因为断言正在被击中。如果您看到了，有人可以指出逻辑错误吗？

谢谢！

我有 WCF 服务 where InstanceContextModeisSingle和ConcurrencyModeis Multiple。目的是在实例化时创建值的缓存，而不会阻止其他不依赖于缓存创建的服务调用。

这样，只有尝试获得读取锁定的方法才_classificationsCacheLock需要等待，直到classificationsCache填充 ( classificationsCacheLock.IsWriterLockHeld = false) 的值。

然而问题是，尽管在任务线程中获得了写锁，调用 WCF 继续服务以响应对服务方法的调用，GetFOIRequestClassificationsList()结果_classificationsCacheLock.IsWriterLockHeld是false，当它应该为真时。

这是WCF实例化的奇怪行为还是我从根本上错过了一个技巧。

我尝试在构造函数的线程上下文（安全选项）和生成的任务线程的上下文中获取写锁（这可能会在调用函数调用比调用调用更快）之间引入竞争，WCF但GetFOIRequestClassificationsList()两者classificationsCacheLock.AcquireWriterLock(Timeout.Infinite);都导致classificationsCacheLock.IsWriterLockHeld尽管false通过使用 thread.sleep 阻止了任何竞争条件，但在每个相应线程的代码块中适当地交错分开。

编辑 1

由于许多建议是围绕线程池中的不确定性以及任务如何处理线程亲和性，我更改了方法以显式生成一个新线程

结果还是一样。分类CacheLock.AcquireReaderLock 不会像它看起来应该的那样等待/阻塞。

我还添加了一些诊断程序来检查是否；

• 该线程实际上是同一个线程，您不能期望 R/W 阻塞同一个线程

• _classificationsCacheLock 的实例始终相同

  公共 GetFOIRequestClassificationsList_Response GetFOIRequestClassificationsList() { 尝试 {

  /li>

结果是..

..按照这个顺序，现在我们有一个预期的竞争条件，因为在新创建的线程中获得了写锁。实际的WCF服务调用是在构造函数的派生线程被安排实际运行之前进行的。所以我搬家

到构造函数，因为这保证在访问任何类字段之前执行。

尽管有证据表明构造函数是在与执行服务方法的线程不同WCF的线程上初始化的，但 AcquireWriterLock 仍然没有阻塞。WCF

同样 AcquireWriterLock 不会阻塞并允许分配空引用分类缓存。

结果是..

编辑 2

创建了没有源代码控制的解决方案副本。

如果您想解决这个问题，请在此处上传。

更改为在代码中使用手动重置事件进行演示，并注释掉问题代码。

• 放置断点
• 在调试中运行 Example.Web
• 在浏览器中导航到“ http://localhost:11164/GetFOIRequestClassificationsList.htm ”并单击按钮。

MRE 有效，ReaderWriterLock 无法按预期工作。

.net 4.0 - C#

我有一个共享队列（使用单例队列包装器实现）以及一个读取器线程和一个写入器线程。当写入线程将元素（入队）添加到队列时，我还有一种机制可以通知读取线程。阅读器线程在收到通知时仅将一个元素出列。在这种情况下是否需要读写锁。

由于作家只是入队和读者出队，我觉得不需要锁，如果读者在出队时检查队列大小。

在创建我的应用程序时。我需要一种结构，这将在下面描述。

我很确定，有一个众所周知的设计模式具有相同的功能，因为我认为我开发它的问题非常普遍。

我编写了自己的实现，但我总是尝试使用模式的“内置语言”实现，所以 - 请帮我命名这个结构。

这个想法接近于读写模式。我们有一个“容器”，我们可以在其中通过键 () 添加对象。我们也可以通过键获取这些对象，将其从容器中移除。

所以，实现的类应该有两个方法：

接下来是最有趣的。 该容器应在多线程环境中工作，如下所示：

1. 如果没有与 key 关联的对象，则在调用 get(Key key) 方法时，调用者线程应等待此容器中的对象。
2. 当另一个线程调用 putObject(Key key, Object object) 方法时，它应该检查是否有一些线程正在等待这个对象，如果是 - 然后发出信号并唤醒等待的线程。

我认为它是常见的结构，它有“官方”名称吗？

我对这种模式的 Java 实现：

我维护了一个用于资源访问的 ReaderWriterLockSlim 对象字典：（示例代码在这里很难看，只是让您了解我的目的）

并像这样使用：

资源可以动态添加或删除，并且它们的生命周期是不可预测的（无法监控资源的删除），随着资源量的增长，rwResourceLocks 的大小也会增加，这将导致内存问题。有没有办法解决这个问题？（显然我不能简单地调用 rwResourceLocks.Clear() 来做到这一点）

我知道这有点复杂:(

我正在尝试在 C 中实现第一个读者作家问题（读者的偏好）。我正在使用互斥锁和解锁来确保如果读者有锁，则没有作家可以访问线程，如果第一个读者可以访问线程读者有一把锁。这是我的代码。我直到最后都无法获得我的代码，即它没有到达线程连接部分。我想我在某个地方遇到了死锁，或者我将互斥锁和解锁放在了错误的位置。

我正在实现一个在内存中保存一些数据的网络应用程序。一些请求读取此数据进行处理，一些请求更新此数据。

在这种情况下，多个读取器可以同时对数据进行操作，但写入器需要独占访问内存中的数据。我想实现一个读写锁来解决这个问题。我还希望以 FIFO 顺序处理锁上的服务员以避免读取和写入饥饿的公平属性。

Haskell 标准库似乎没有提供这样的功能。我发现concurrency-extra提供了此功能，但该库似乎未维护（并在 LTS 3.22 之后从堆栈中删除） - 我不清楚它的公平性。

我发现在标准的 haskell 库和堆栈中没有读写器锁库有点令人惊讶——读写器模式在许多软件中不是很常见吗？或者在 Haskell 中是否有一种完全不同的（可能是无锁的）方法？

编辑：更准确地说，在公平属性上，当写入器被阻塞等待获取锁时，只有在写入器获取并释放写入锁之后才允许后续的读锁请求 - 类似于MVars 公平属性 - MVars 有一个 FIFO财产

我正在尝试实现 Reader/Writer 锁定机制来控制 3 个线程的同步，每个线程基于随机抽取骰子执行 4 次。例如，对于线程 i，调用 random.randint(1, 6)，如果输出为偶数，则读取线程 i，如果为奇数，则写入线程 i。在这里，我找到了读/写锁的一般实现，但是我没有成功为 3 个线程执行这 4 个操作。这是原始代码的一部分以及我最后的补充：

有什么建议吗？