问题标签 [readerwriterlockslim]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - 关于 ReaderWriterLockSlim 的问题。我使用 readerwriterlockslim 进行读写，但最后只在控制台中显示 write。为什么？
这是代码：
我想测试ReaderWriterLockSlim，我期望的结果是在控制台中交替读取和写入，但最后只能在控制台中写入。
结果如下：
但是当使用 ReaderWriterLock 时，它的替代显示。结果如下：
为什么会出现这种情况，有人告诉我这种现象的原因吗？希望回答
c# - EnterWriteLock 和 TryEnterWriteLock(Timeout.Infinite) 的区别
我对 ReaderWriterLockSlim 的参数之间的区别EnterWriteLock()和TryEnterWriteLock()与作为参数的区别有点困惑。Timeout.Infinite为进入锁而不是直接使用 EnterWriteLock 提供无限超时有什么意义？我所理解的这两种方法是完全一样的？我错过了什么？
c# - Intellocked.Exchange 而不是 ReaderWriterLockSlim
在多线程应用程序中，我有一个由多个线程访问的字典，用于获取特定键的值。还有一种使用 Quartz.Net 的机制来更新这个字典。我正在尝试找到使更新后的字典可用于以线程安全方式阅读的最佳方法。最初，我将 ReadWriterLockSlim 视为一种解决方案，但当我搜索可能的性能损失时，我可能遇到了 Interlocked.Exchange 和可用于对象的重载。所以我的问题是，它可以在这种情况下使用吗？我提供了它的用法的代码示例。
非常感谢
编辑：
由于有一个downvote，我添加了一些更多信息：
请注意以下段落：“如果写入很少，您可以通过将集合视为不可变并在它更改时生成一个全新的列表来获得更好的性能。然后您可以使用 Interlocked.CompareExchange 更新对线程中列表的引用-安全的方式。这应该可以防止读者需要制作防御性副本（如果阅读比写作更普遍，这应该是一个巨大的胜利）并消除对锁定的需要。
关于 Intelocked.CompareExchange 方法，这里提供了一个见解：Using Interlocked.CompareExchange with a class
请注意，正确的架构设计是使用默认线程安全的 MemoryCache 和 pub/sub 机制来反映缓存项的更改 - 但是它不是由我设计的，我怀疑是否有希望改变不久的将来。
concurrency - 读取和写入时间 - 特定于应用程序
相比之下，我一直在考虑读取时间比写入时间长的实际应用程序。基本上，我试图了解读写锁的实用性，我偶然发现了以下博客文章： Beware of RW locks where，作者提到当预期的读锁持有时间需要相当长时，使用 RW 锁是有意义的，而写入涉及快速更新。这引出了可能存在这种情况的实际应用程序的问题。
在最初的搜索中，我遇到了讨论分布式数据库中的读取延迟的文章，但读取延迟还涉及获取锁的时间，而不仅仅是实际读取的平均时间（例如this）。
附带说明一下，这个 stackoverflow 问题的答案很有趣。
c# - 多线程函数中的 LockRecursionException
我不知道如何描述它，但是当代码写得很好时，我得到了一个例外。此异常与 ReaderWriterLockSlim 有关，它是 LockRecursionException；它出现在“ScreenLocker.EnterReadLock();” 线。在我的代码和描述中找不到问题，或者在互联网上可能有什么问题，这就是为什么我在这里写这个问题并向大家寻求帮助。这是我有问题的代码：
这些是此方法调用的函数：
你怎么能看到我在进入 XAxysScan 函数后立即释放锁定。
c# - 通过 System.Text.Json.Serialization 将对象序列化为文件似乎会破坏 ReaderWriterLockSlim
我需要一个简单的 List<> 在异步环境中使用并且是并发的。该列表确实只有一堆方法，而不是 IList 的完整实现。我已经使用 ReaderWriterLockSlim 类来启用锁定范例并且它运行良好。
最近在进行单元测试时，我收到了一个锁定错误：System.Threading.LockRecursionException：“在此模式下持有的写锁可能无法获取读锁。” 并且属性 IsWriteLockHeld 在异常点为真。这根本不是预期的，代码似乎很好。
因此，我启动了一个小型控制台测试程序，发现使用 System.Text.Json.Serialization 命名空间将我的列表序列化为文件会导致问题。如果我评论了将列表序列化为文件的调用，那么一切都会按预期工作。
单步执行代码时，程序似乎在 Save() 之后的下一个读/写锁上死锁，并且即使属性 IsReadLockHeld 和 IsWriteLockHeld 为假也不会返回。
示例代码中没有抛出异常。
我将不胜感激任何意见或建议。我不知所措。这是信号量或序列化程序中的缺陷，还是我彻底搞砸了我的代码。
带有注释的示例代码如下。