Question

我们已经用</ p>实现了一个读写器锁

 typedef boost::unique_lock<boost::shared_mutex> WriterLock;
 typedef boost::shared_lock<boost::shared_mutex> ReadersLock;

我们有很多多线程读者，只有少数作家。读者与其他读者共享访问权限但阻止作者。 Writer阻塞，直到它具有对资源的独占访问权限。

我们在增强文档中找不到这个... 防止作家饥饿的政策是什么？例如，如果有许多读者都在从线程池中敲击锁定，那么在编写器最终获取锁定之前，锁定尝试次数是否有任何保证上限？

我们一直看到性能数字似乎表明写入必须等到根本没有读者，而且很少有情况需要很长时间，因为新读者可以在当前读者服务时请求锁定。在这种情况下，似乎在我们的代码中，作者必须等待很长时间，直到根本没有读取。

我们更喜欢像系统这样的更多队列，当写入者请求锁定时，所有当前的读取器都会耗尽，但所有新的传入读取器都会阻止写入请求。

Boost中可升级锁定概念的行为是什么？ Boost threads

它没有说出它如何处理作家饥饿。

Answer 1

@ Guerrero解决方案的一个小改进，增加了多个读者和多个作家的公平性，因此没有人会饿死：

read() {
    while (atomic-write-requests > 0)
        condition.wait();
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    while (atomic-write-requests > 0)
        condition.wait();
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}

在这个解决方案中，每当作家离开范围时，都会开始新的公平竞争。

Answer 2

在不了解boost实现的情况下，也许您可以通过实现来防止编写器饥饿。读者可以在作家存在的情况下等待。也许就像这个伪代码：

read() {
    while (atomic-write-requests > 0) {
        condition.wait();
    }
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}

Answer 3

如果你想要的是一个fifo方法，boost在其状态图库上实现了几种调度策略（包括FIFO）。我猜你将不得不调整你的很多代码来使用它。查看有关fifo_scheduler和FifoWorker的文档：

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#FifoWorker

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#fifo_scheduler.hpp

读写器锁的boost :: unique_lock和boost :: shared_lock

3 个答案: