问题标签 [readerwriterlockslim]

我有以下代码：

Locker.TryEnterReadLock超时。如果我在它超时之前停止调试器，Locker.IsWriteLockHeld两者Locker.IsReadLockHeld都是false.

问题：为什么 TryEnterReadLock 在这种特殊情况下会等待？

[编辑] 确实，如评论中所示，我在检查您的 if 条件和进入if块之间已锁定。所以，我试图删除if并留下 just Locker.TryEnterReadLock(WaitTimeout);，但我收到以下错误：

附加信息：在此模式下持有写锁可能无法获取读锁。

事实上，其他一些线程有一个写锁（Locker.IsWriteLockHeld = true）。

我想要的是lock当一个线程具有写锁时获得经典锁定，即让线程等到它完成，但我找不到方法来做到这一点。

在FileWriter将由不同线程使用的类中，我目前使用 aReaderWriterLockSlim来防止两个线程尝试同时写入文件时发生错误，如下所示：

这确实有效。但在那之后，我读到了ReaderWriterLockSlimimplements IDisposable，所以我想知道是否

将是“更好”的方法，以及它是否会引入一些新的缺点。我的直觉告诉我，我可能不应该在ReaderWriterLockSlim每次调用该方法时都创建一个新方法，而应该只创建一次，如(2).

可悲的是，它不起作用（就好像我什至没有使用过锁一样），所以我认为这(2)是不正确的。但是话又说回来，如果不打算像 in 那样使用它，为什么还要ReaderWriterLockSlim实施呢？IDisposable(2)

的正确用法是ReaderWriterLockSlim什么？

ReaderWriterLockSlim 的很多例子都是这样写的：

EnterLock 在 try 块之外是否有真正的原因？

我需要锁定我的代码的特定部分，问题如下：

我必须允许多个读取线程和单个写入线程到该部分，例如：

我正在构建一个 UI，该 UI 由一个主表单以及其他表单和自定义类的可能实例组成。我仍然缺少的是记录错误的一致方式。所以我所做的是围绕所有可能产生错误的代码创建 try-catch 块，主要是处理传入数据的东西。我从某个站点接收恒定数据流 (JSON)，因此框架的内置线程功能使其成为多线程应用程序。同样，多线程部分是内置功能，我自己并没有积极地这样做，因为从 C# 的角度来看，我还没有那么聪明。;)

对于日志记录部分，我从这里得到了下面的代码。尽管我还没有那么聪明，但我确实认为我确实了解那里发生的事情。然而，我的关注/问题是：我如何实现一种多线程日志记录机制，将错误写入一个日志文件跨表单跨类。

这是一个您可以使用参考的示例：

所以基本上对我来说重要的是我应该把 WriteToFileThreadSafe() 和 _readWriteLock 放在哪里？以及如何在多个表单和类的多个线程中安全地使用此功能？

非常感谢您让我向您的大师学习:)

我对警告感到困惑ReaderWriterLockSlim SupportsRecursion

来自MSDN

默认情况下，ReaderWriterLockSlim 的新实例是使用 LockRecursionPolicy.NoRecursion 标志创建的，并且不允许递归。建议所有新开发使用此默认策略，因为递归会引入不必要的复杂性并使您的代码更容易出现死锁。

我不明白为什么这个警告不适用于lock递归的内置语句？

我写了一个相当简单的包装ReaderWriterLockSlim：

（这可能不是世界上最有效的事情，所以我也对这个类的建议改进感兴趣。）

它是这样使用的：

（有大量的读取非常频繁地发生，几乎从没有写入。）

这似乎总是在发布模式和生产中按预期工作。但是在调试模式和调试器中，进程偶尔会在特殊状态下死锁——它调用EnterReadLock了，锁本身不被任何东西持有（所有者为 0，报告它是否有任何读取器/写入器的属性/服务员说不是，等等）但里面的自旋锁被锁住了，它在那里无休止地旋转。

我不知道是什么触发了这个，除了如果我在断点处停止和单步执行（在完全不相关的代码中）它似乎更频繁地发生。

如果我手动将自旋锁_isLocked字段切换回 0，则该过程将恢复，之后一切似乎都按预期工作。

密码或锁本身有问题吗？调试器是否正在做一些事情来意外引发自旋锁死锁？（我使用的是 .NET 4.6.2。）

我读过一篇文章，指出这ThreadAbortException可能是这些锁的问题——我的代码Abort()在某些地方确实有调用——但我不认为那些涉及调用这个锁定代码的代码（尽管我可能是错误）并且如果问题是锁已被获取并且从未释放，那么它应该与我所看到的不同。（尽管顺便说一句，框架文档明确禁止在受限区域中获取锁定，正如那篇文章所鼓励的那样。）

我可以更改代码以避免锁定间接，但一般情况下不是using守卫推荐的做法吗？

我正在尝试实现一个可快速访问且仅偶尔更新的线程安全资源池。为此，我使用带有扩展方法的 ReaderWriterLockSlim 来进入和退出读锁。虽然分析线程利用率出乎意料地非常低。

我验证池中没有发生写入，因此从未调用 EnterWriteLock()。

在进行分析时，我发现大多数线程将大约 25% 的时间花在 EnterReadLock() 中。该函数的内部睡眠大约需要 19%，其余时间用于主动旋转和其他开销。我希望 EnterReadLock 根本不会睡觉，只会旋转一小段时间。有没有办法提高利用率并减少等待时间？

我有一个有两种方法（一个实例）的类：

DoSomething允许多个线程同时访问。但是，如果Connect被调用，则不允许线程进入DoSomething，反之亦然，所以Connect和DoSomething是互斥的。 DoSomething比 更频繁地调用Connect。

我的第一个想法是使用ReaderWriterLockSlim，但是，当DomeSomething获取 reader lock 并需要调用Connect自身时，它无法获取 writer lock in Connect。

哪种同步模式最适合实现这一目标？

我有一个state变量，其感兴趣的字段是thread-safe并一直fresh使用一个ReaderWriterLockSlim。我已经细化了对所有字段的访问，因为我在其他地方单独使用它们。

虽然对于字段的单独访问它工作正常，但我还需要进行一些原子操作。在这种情况下，我需要额外的操作lock吗？

我有一个已经包含thread-safe字段的状态变量：

我已经有了这个线程安全的，并且我确保线程从内存中读取而不是从本地缓存中读取。但是我需要多个操作来完成原子操作。

原子操作

正如您在我的文章中看到的那样，我while有一个if-else需要原子操作组的地方。我应该使用额外的lock还是有其他一些轻量级的解决方案？