问题标签 [readerwriterlockslim]

ReaderWriterLockSlim 允许使用锁来管理对资源的访问，允许多个线程进行读取或独占访问进行写入。目前我们有以下代码：

现在，如果我需要保护 A 和 B 类型对象的数据，应该采用什么方法，为什么？

我ReaderWriterLockSlim用来保护一些操作。我想偏爱读者而不是作者，这样当读者长时间持有锁并且作者试图获取写锁时，进一步的读者不会被作者的尝试阻塞（如果作者被屏蔽了lock.EnterWriteLock()）。

为此，我认为作者可以TryEnterWriteLock在循环中使用短暂的超时，以便后续读者仍然能够获得读锁，而作者不能。然而，令我惊讶的是，我发现一个不成功的调用TryEnterWriteLock改变了锁的状态，无论如何都会阻塞未来的读者。概念验证代码：

这段代码的输出是：

如您所见，即使线程 2（“写入器”）尚未获得写入器锁并且它不在EnterWriteLock调用中，线程 3 也会被永久阻塞。我可以看到类似的行为ReaderWriterLock。

我做错什么了吗？如果不是，当作家排队时，我必须有哪些选择来支持读者？

给定下面的简单套接字客户端类，将其连接到 TCP 服务器（我使用 SocketTest3，可在线免费获得）。然后断开服务器并稍等片刻。你应该得到一个LockRecursionException.

我不明白为什么在给出的简化示例中会发生这种情况。我知道我应该ReceiveOne在收到零长度消息后立即停止呼叫，但这更像是一种练习。我想知道类似的错误是否可以保持在后台运行的持续回调流并窃取资源而不会发生明显的坏事。我必须承认我没有预料到这个特殊的例外。

问题1：为什么会这样？是否BeginXYZ允许方法在同一个线程上立即执行回调？如果是这样，谁能说这在正常运行时不会发生？

问题 2：在这种情况下，有没有办法在保持“所需”行为的同时避免出现此异常？我的意思是触发不间断的回调流。

我正在使用带有 .NET 4 的 Visual Studio 2010。

我需要同时允许多个作者/单个读者。

我找到了ReaderWriterLockSlim类，但命名有问题。我需要使用 EnterReadLock() 来允许写入器写入，使用 EnterWriteLock() 来允许读取器写入，这对于进一步使用可能会有点混乱。

ReaderWriterLockSlim 类是否有针对我的问题的包装类，或者您能否提出其他解决方案。

谢谢！

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

并像这样使用：

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

我知道这有点复杂:(

如何知道 ReaderWriterLockSlim 当前是否被另一个线程写锁定？

是的，我可以调用 rwls.TryEnterWriteLock(1) 来检查它是否被写锁定，但这会降低性能

有没有直接的方法来获得写锁定状态？

我有一个由一个专用线程管理的数据库写入操作队列。而且我有很多线程可以随时从数据库中读取。

我正在使用 ReaderWriterLockSlim 进行读/写访问控制。

我的问题是 - 为什么不推荐 LockRecursionPolicy.SupportsRecursion？MSDN 文档说：

不建议在新开发中使用递归，因为它会引入不必要的复杂性并使您的代码更容易出现死锁。

这里如何实现死锁？例如，如果我在已经获取 WriteReadLock 时尝试调用 EnterReadLock（并且我在 SupportsRecursion 策略下），我会得到一个异常......

我发现 Windows 实现了一个纤薄的读写器锁（参见https://msdn.microsoft.com/en-us/library/windows/desktop/aa904937%28v=vs.85%29.aspx）。不幸的是（对我来说）这个 rw-lock 既不是先进先出也不公平（在任何意义上）。是否有可能通过一些解决方法公平或先进先出使 Windows rw-lock？如果不是，您会在哪些情况下使用 windows slim rw-lock？

我使用 AcquireSRWLockShared 和 AcquireSRWLockExclusive Windows API 围绕非线程安全映射提供了一个瘦包装器。本质上，与查找相关的方法正在使用读锁，而“设置”相关方法正在使用写锁——很简单，直截了当。

这是皱纹：我正在重构旧代码，其中一个要求是调用者需要能够在“集合级别”锁定此映射，然后对其进行不同的调用——所有这些都“在一个事务下”以便说话。

问题是，如果我要获取写锁并保持它，那么如果我要进行查找 - Lookup 方法正在尝试获取将失败或阻塞的读锁。好像我在一个篮子里塞进了 2 种不同的方法，但它只是没有发生。

我能想到的唯一解决方法是我应该使用一个不区分读者和作者的普通临界区——并且同一个线程可以多次进入同一个临界区。那会很糟糕，因为我真的很想获得单个作者/多个读者的性能。有任何想法吗？

我创建了一个CachedRepository如下所示的泛型：

通过使用通用对象来锁定，我将获得每种类型的锁定（即处理不同类型的线程不会一个接一个地等待）。但是，此类用于很少更改但读取量很大的对象列表，因此使用简单锁定lock将延迟读取器，直到另一个读取器完成。

我查看了ReaderWriterLockSlim，但它不是通用类，如果我使用它，我会失去我现在拥有的类型锁定。

问题：如何在保持lock(generic_type_instance)模式提供的类型锁定的同时减少对读者的锁定？