我们有针对 .NET 2.0 RTM 的项目（是的，它应该是 .NET 2.0 RTM，我们有一些正统的客户端）。我只是想知道ReaderWriterLock的缺点是什么？为什么每个人都说“不要使用它，尝试使用其他类似lock声明”的东西如此糟糕？如果我们可以使用 .NET 3.5，我肯定会使用ReaderWriterLockSlim，但ReaderWriterLock我有点害怕所有这些警告来自各处。有没有人测量性能或其他什么？如果存在一些性能问题，我们可以在什么有效负载下遇到它们？

就主要目的而言，我们有一个经典的情况ReaderWriterLock，即多读少写。usinglock语句会阻塞所有读者。也许这对我们来说不是一个可怕的问题，但如果我可以使用ReaderWriterLock我会更满意。IMO 引入多台显示器确实是一个非常非常糟糕的主意。

当您想使用 a 时ReaderWriterLock，您可以像这样声明它：

ReaderWriterLock rwLock = new ReaderWriterLock;

好吧，如果您为所有要访问您要保护的资源的不同线程执行此操作，那么它们（可能）都使用不同的 ReaderWriterLock 实例。

ReaderWriterLock 实例如何在线程之间共享？

另外，作为奖励，有人可以为我确认您真正“锁定”的是 ReaderWriterLock 状态，而不是任何资源。与 不同lock(someResourceToLock)的是，除了 ReaderWriterLock 实例的状态（无论它是处于读取模式还是写入模式，以及您是否被允许读取和写入）之外，您不会锁定任何东西。

我正在为 iphone dev 实现 pthread_rwlock_t 的包装器。文档说在获取写锁后获取读锁是未定义的。POSIX 是否允许我查询我是否已经拥有写锁？或者，防止这种情况发生的最好方法是什么？

谢谢！

这是reader writer 的一种实现，即很多reader 可以读，但在任何时候只有一个writer 可以写。这是否按预期工作？

这个实现与声明每个方法有什么不同吗

例如？

谢谢

故事

有一个作家线程，定期从某个地方收集数据（实时，但这在问题中并不重要）。然后有很多读者从这些数据中阅读。通常的解决方案是使用两个读写器锁和两个缓冲区，如下所示：

或者

问题

在这两种方法中，如果获取其他锁操作失败，则不会进行任何交换，并且写入器将覆盖其先前的数据（因为写入器是实时的，它无法等待读取器）所以在这种情况下，所有读取器都会丢失该帧数据的。

不过这没什么大不了的，阅读器是我自己的代码，而且它们很短，所以使用双缓冲，这个问题就解决了，如果有问题，我可以让它成为三缓冲（或更多）。

问题是我想尽量减少延迟。想象案例1：

在**此时**，理论上其他读者可以读取数据，buffer0只要作者可以在读者完成后进行交换而不是等待下一个周期。在这种情况下发生的情况是，仅仅因为一个阅读器迟到了，所有阅读器都错过了一帧数据，而这个问题本来可以完全避免。

案例2类似：

我尝试混合解决方案，因此作者在写入后立即尝试交换缓冲区，如果不可能，则在下一个时期醒来后立即交换。所以是这样的：

现在延迟问题仍然存在：

同样在**此时**，所有读者都可以开始阅读buffer0，这是在写入后的短暂延迟buffer0，但他们必须等到写入器的下一个周期。

问题

问题是，我该如何处理？如果我希望编写器在所需的时间段精确执行，则需要使用 RTAI 函数等待该时间段，我不能这样做

这引入了抖动。因为“几次”可能碰巧比“等待下一个时期”更长，所以作者可能会错过其时期的开始。

为了更清楚，这就是我想要发生的事情：

我已经找到的

我发现read-copy-update据我了解，它一直为缓冲区分配内存并释放它们，直到读者完成它们，这对我来说是不可能的，原因有很多。一，线程在内核和用户空间之间共享。其次，使用 RTAI，您不能在实时线程中分配内存（因为那样您的线程将调用 Linux 的系统调用，从而破坏实时性！（更不用说使用 Linux 自己的 RCU 实现了，因为出于同样的原因）

我还考虑过有一个额外的线程以更高的频率尝试交换缓冲区，但这听起来不是一个好主意。首先，它本身需要与 writer 同步，其次，我有许多这样的 writer-readers 并行工作在不同的部分，每个 writer 一个额外的线程似乎太多了。在与每个作者同步方面，所有作者的一个线程似乎非常复杂。

我目前正在研究读写器问题的正确实现（请参见此处）。

我在 Qt 坞站中找到了这个解决方案，通过使用信号量和互斥体来保证对 Reader 和 Writer 线程的公平处理。基本代码是这样的：

这似乎是一个非常优雅的解决方案。它似乎比这个SO 答案pthread_rwlock_*中详述的行为更容易、更有效。

我想知道下面的代码是否是对 Qt 解决方案的正确调整，以更喜欢 Reader 线程。

在操作系统书籍中，他们说必须有一个锁来保护数据不被读写器同时访问。但是当我在 x86 机器上测试这个简单的例子时，它运行良好。我想知道，这里的锁是必需的吗？

有没有更快的那种TMultiReadExclusiveWriteSynchronizer？也许是 FastCode？

从 Windows Vista 开始，Microsoft 添加了Slim Reader/Writer lock。它的性能比 Delphi 的TMultiReadExclusiveWriteSynchronizer. 不幸的是，它只存在于 Windows Vista 及更高版本中，实际上很少有客户拥有。

大概 a 中使用的概念Slim Reader/Writer lock可以在本机 Delphi 代码中重做 - 但有人做过吗？

我有一种情况，在 a 上获取和释放锁TMultiReadExclusiveWriteSynchronizer（即使没有争用 - 单个线程）会导致 100% 的开销（操作时间加倍）。我可以在没有锁定的情况下运行，但是我的类不再是线程安全的。

有更快的TMultiReadExclusiveWriteSynchronizer吗？

注意：如果我使用 aTCriticalSection我只会遭受 2% 的性能损失（尽管已知关键部分在获取成功时会很快，即当它是单线程并且没有争用时）。CS 的缺点是我失去了“多个阅读器”的能力。

测量结果

使用TMultiReadExclusiveWriteSynchronizer相当多的时间花在里面BeginReadand EndRead：

然后，我将代码移植到使用 Window 自己的SlimReaderWriter 锁（一些代码重写，因为它不支持递归锁获取），并分析了结果：

• TMultiReadExclusiveWriteSynchronizer: 10,698 ns 每次迭代
  10,697,772,613 ns 迭代 1,000,000 次

• SRWLock: 8,802 ns 每次迭代
  8,801,678,339 ns 迭代 1,000,000 次

• Omni Reader-Writer lock: 8,941 ns 每次迭代
  8,940,552,487 ns 迭代 1,000,000 次

使用 SRWLocks（又名 Omni 的旋转锁）时提高了 17%。

现在，我无法永久切换代码以使用Windows Vista SRWLocks，因为有一些完整的客户企业仍在使用 Windows XP。

Slim 锁只是对InterlockedCompareExchange功能的谨慎使用；但比我能成功使用的要小心。我离窃取所涉及的 140 条机器指令还差得很远，并且已经完成了。

奖金阅读

• 关键部分总是更快吗？
• 如何编写快速的多线程 Delphi 应用程序

我正在尝试使用名为信号量的 POSIX 制作一个简单的读取器/写入器程序，它可以工作，但在某些系统上，它会在第一个信号量时立即停止，仅此而已......我现在真的很绝望。有人可以帮忙吗？它在我的系统上运行良好，所以我无法通过 ltrace 跟踪问题。（抱歉评论，我来自捷克共和国）

https://www.dropbox.com/s/hfcp44u2r0jd7fy/readerWriter.c

以上是作者优先于读者的读者写问题解决方案。

假设最初有 1000 个读取器开始执行代码来读取数据（假设读取数据代码很大，每个线程需要 1 秒），然后 1 个写入器尝试写入数据。所以作者必须等待 1000 个读者首先完成（即 1000 秒）。

例如，在一个应用程序中，1 个 writer 更新时间，许多 reader 读取时间，writer 必须等待 1000 秒，这是巨大的。

是否有任何解决方案，当作者尝试写入时，所有读者都将被抢占，直到作者完成其任务？