boost::unique_lock 和 boost::shared_lock 用于读写锁

Question

我们已经实现了读写锁

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

我们有许多多线程读取器，但只有少数写入器。读者与其他读者共享访问权限，但阻止作者。Writer 会阻塞，直到它拥有对资源的独占访问权。

我们在 boost 文档中找不到这个...防止 Writer 饥饿的策略是什么？
例如，如果有许多读者都从线程池中获取锁，那么在写入者最终获取锁之前，是否有保证尝试锁的次数上限？

我们看到的性能数据似乎表明写入必须等到完全没有读取器为止，并且在极少数情况下会等待很长时间，因为新读取器可以在当前读取器得到服务时请求锁定。在这种情况下，在我们的代码中，编写者似乎必须等待很长时间，直到根本没有读取。

我们更喜欢一个更像队列的系统，当写入者请求锁定时，所有当前的读取者都会耗尽，但所有新传入的读取者都会阻塞在写入者请求之后。

Boost 中可升级锁概念的行为是什么？ 提升线程数

它没有说明它如何处理作家饥饿问题。

Answer 1

在不了解太多关于 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();
}