相当于c++ 11中的boost shared_mutex

我尝试但未能获得shared_mutex进入c++ 11。它已被提议作为未来的标准。提案在这里。

Edit: c++ 14的修订版本(N3659)已被接受。

下面是一个实现:

http://howardhinnant.github.io/shared_mutex

http://howardhinnant.github.io/shared_mutex.cpp

简单…没有。没有标准的c++实现读写锁。

但是，这里有几个选项。

1. 你可以在自己的设备上设置你自己的读写锁。
2. 使用特定平台的实现，如Win32的，POSIX的，或Boost的，如你提到的。
3. 不要使用互斥锁——使用c++ 11中已经存在的互斥锁。

使用#1并实现你自己的是一项可怕的任务，如果你做得不对，可能会让你的代码充满竞争条件。有一个参考实现可以使工作更容易一些。

如果你想要平台无关的代码，或者不想在代码中包含任何额外的库，比如读写锁，你可以把#2扔出窗外。

并且，#3有一些大多数人没有意识到的注意事项:使用读写锁通常性能较差，并且与使用简单互斥锁的等效实现相比，代码更难以理解。这是因为在读写锁实现的幕后必须进行额外的簿记。

---

我只能给你你的选择，真的是由你来权衡每一个的成本和收益，选择一个最好的。

---

编辑:

c++ 17现在有了shared_mutex类型，用于具有多个并发读取器的好处超过shared_mutex本身的性能成本的情况。

不，c++ 11中没有相应的boost::shared_mutex。

在c++ 14或更高版本中支持读写锁，但是:

• c++ 14新增std::shared_timed_mutex
• c++ 17新增std::shared_mutex

区别在于std::shared_timed_mutex增加了额外的计时操作。它实现了SharedTimedMutex概念，这是std::shared_mutex实现的更简单的TimedMutex概念的扩展。

---

请记住，获取读/写互斥锁的代价要比获取普通的std::mutex高。因此，如果有频繁的短读操作，读/写互斥锁不会提高性能。它更适合于读取操作频繁且代价昂贵的场景。引用Anthony Williams的帖子:

锁shared_mutex的代价比锁a的代价高普通的std::互斥锁，即使对于读线程也是如此。这是一个必要的部分有更多可能的a的状态Shared_mutex不是互斥锁，代码必须正确处理它们。这成本来自于对象的大小(这在你的实现和我的POSIX实现都包括一个普通互斥锁和一个条件变量)，以及在性能上的锁和锁操作。

而且，shared_mutex是一个争用点，因此不是可伸缩的。锁定shared_mutex必须修改对象的状态互斥锁，即使是读锁。因此，保存Shared_mutex状态必须转移到任何处理器执行锁定或解锁操作。

如果你有很多线程执行频繁的短读操作，在多处理器系统上，这会导致大量缓存乒乓球，这将大大影响性能系统。在这种情况下，您不妨采用更简单的just的设计使用普通互斥锁，因为读取器基本上是序列化的。

如果读不频繁，则没有争用，所以不使用需要担心并发读取，一个普通互斥就足够了

如果读操作耗时，则此结果争论不太明显，因为它与花费的时间相比是微不足道的持有读锁。但是，执行耗时的操作而拿着锁是一种设计的味道。

在绝大多数情况下，我认为有更好的shared_mutex的替代方案。这可能是一个普通的互斥，原子支持shared_ptr，使用精心构造的并发容器，或其他东西，取决于上下文。