问题标签 [readerwriterlock]

这对我来说似乎很吵。五行开销实在是太多了。

那你怎么会这么简单？

我有一个由于死锁而挂起的 .Net 进程的转储（gui 线程不再响应，我的日志显示某些线程已停止响应）。我已经拍了一张快照，现在正在windbg中查看它，所有线程都在等待最后一个。用 !clrstack -p 查看那个线程的堆栈跟踪，我可以看到它正在尝试获取对 ReaderWriterLock 的写入

我如何知道哪个其他线程持有该锁，以便我可以开始弄清楚死锁是如何发生的？

谢谢

[编辑] .Net1.1 sos.dll 中显然有一个命令 !rwlocks 可以帮助解决这个问题，但 .Net2.0 版本中没有。狩猎继续

我有一个IDictionary<TKey,TValue>内部保存 n other 的实现，Dictionary<TKey, TValue>并通过键的 HashCode 将插入分发到各个子字典。有 16 个子字典，在 4 核机器上的冲突数量非常低。

对于并行插入，我用 a 锁定了 Add-method ReaderWriterLockSlim，只锁定了单个子字典：

当插入具有四个线程的项目时，我只有大约 32% 的 cpu 使用率和糟糕的性能。所以我用监视器（即lock关键字）替换了 ReaderWriterLockSlim。CPU 使用率现在接近 100%，性能提高了一倍以上。

我的问题是：为什么 CPU 使用率会增加？碰撞次数不应改变。是什么让 ReaderWriterLock.EnterWriteLock 等了这么多次？

您好，我需要在我的方法中使用 writerreaderlock。我想知道如何正确使用它。

我有一本 ObjectA 的字典

在我的方法中，我使用 ObjectA 的字典，键是 Guid，所以假设当我调用 dict[guid] 它总是返回我的 ObjectA 的实例（例如）

我真的不确定我在那里使用读写器，我需要如何使用读写器锁，有条件验证？

我在 .net 2.0 中有应用程序，其中我的应用程序中有一个全局的 DataTable 对象，并且在整个应用程序中有不同的数据视图。

当执行一个动作时，我创建了许多线程，比如说 5 个线程，其中数据是从不同的数据视图读取的，同时 2/3 线程正在读取数据（不是所有 2 个线程要读取数据），一个线程在数据表中写入数据。所以我们得到像“枚举更新”或“参数不为空”类型的异常。

我为此使用了 ReadWriteLock，但没有发现它在 ReaderWriterLock.AcquireWriterLock() 上停止的任何运气。

我不明白我在哪里做错了。

如果有人有任何想法。请帮助我如何为数据表和数据视图实现此场景的 ReaderWriterLock。

谢谢！！

可以说，我有一个读写器系统，其中读写器同时运行。'a' 和 'b' 是两个共享变量，它们是相互关联的，所以对它们的修改需要是原子操作。

读写器系统可以是以下类型：

1. rr
2. 万维网
3. 读写
4. r-ww
5. rr-w
6. rr-ww

其中
[ r : 单
读 rr: 多读
w : 单写
ww: 多写]

现在，我们可以有一个读取器的读取方法和一个写入器的写入方法，如下所示。我已经按照系统类型编写了它们。

1. rr

   /li>

2. 万维网

   /li>

3. 读写

4. r-ww
5. rr-w

6. rr-ww

   /li>

对于多阅读器系统，共享变量访问不需要是原子的。

对于多写入器系统，共享变量访问需要是原子的，所以用'm'锁定。

但是，对于系统类型 3 到 6，我的 read_method 和 write_method 是否正确？我该如何改进？

此致，
斯里尼瓦斯纳亚克

当我使用 lock(){...} 时，我无法保证哪个线程将首先进入锁。

ReaderWriterLock 呢？它是否像作家的 FIFO 一样工作？

是否有跨进程工作的读/写锁定机制（类似于互斥锁，但读/写而不是排他锁定）？我想允许并发读取访问，但独占写入访问。

与 ReaderWriterLock（或 ReaderWriterLockSlim）一起使用时，有序锁定模式是否可以防止死锁？

显然，该模式可以防止互斥锁死锁。如果我用（（N 个带读锁的资源）和（1 个或 2 个带写锁的资源））锁定多个资源，它是否仍然可以防止死锁。

例如：（粗体数字代表具有写锁的资源）

1 2 3 4 5

2 3 4

1 4 5

我正在尝试找到（或实现）支持低优先级写入器的读取器/写入器锁，但在研究任何现有解决方案时均未成功。

我所说的低优先级作家的意思是：“将让位”给新来的读者或普通作家。

如果有源源不断的读取器肯定会导致饥饿，但这可以通过定时锁变体（“尝试定时低优先级写入器锁”，然后在超时时切换到普通锁）或通过改变读取器的方式来解决发出（可能会定期停止读取一个短窗口）。

如果有任何文献描述了这些内容，我还没有找到。

如果有利用常规锁的已知（正确！）解决方案，我将不胜感激。