带有 std::shared_lock 的 std::shared_mutex 是读者还是作者更喜欢？答案

【问题标题】：std::shared_mutex with std::shared_lock is reader or writer preferring?带有 std::shared_lock 的 std::shared_mutex 是读者还是作者更喜欢？
【发布时间】：2017-04-09 16:50:41
【问题描述】：

在读写锁的实现中，我们可以使用std::shared_mutex与std::shared_lock和std::lock_guard或std::unique_lock。

问题>是这个新功能的作者还是读者更喜欢？

根据 Andrew 的评论更新

Reference:

  // Multiple threads/readers can read the counter's value at the same time.
  unsigned int get() const {
    std::shared_lock<std::shared_mutex> lock(mutex_);
    return value_;
  }

  // Only one thread/writer can increment/write the counter's value.
  void increment() {
    std::unique_lock<std::shared_mutex> lock(mutex_);
    value_++;
  }

从上面的例子可以看出，我无法控制读写器的优先级。

【问题讨论】：

如果你实现自己的读/写锁，那不取决于你是如何实现的吗？
@AndrewHenle 请检查我的更新问题。

标签： c++ c++17

【解决方案1】：

在实践中：

libc++ 总是使用 Howard 提到的互斥+条件变量技术，这并不奇怪。
libstdc++ 在可用的情况下使用pthread_rwlock_t，如果不是，则回退到霍华德提到的算法。因此，如果pthread_rwlock_t 可用，则使用的算法取决于 pthreads 实现。我相信 glibc 默认更喜欢阅读器。
MSVC 使用 Windows SRWLOCK，其 documentation 表示

无法保证请求的线程的顺序所有权将被授予所有权； SRW 锁既不公平也不公平先进先出。

【讨论】：

【解决方案2】：

两者都不是（如果实施得当）。相反，读者和作者通过公平技术被选为下一个。这就是这个特性既不能在 API 中设置，也不能指定的原因。

This answer 详细说明了这是如何实现的。

【讨论】：