c++11线程的RW锁

A RW lock for c++11 threads

本文关键字：RW 线程 c++11      更新时间：2023-10-16

我想使用新的标准线程而不是boost:threads，但我注意到旧的shared_mutex不可用。替换这个功能并给我一个多读单写锁的好建议是什么?

std::shared_mutex将成为c++ 14标准库的一部分。

你仍然可以使用boost::shared_mutex。在Windows下，如果你使用的是Windows Vista或更高版本，你可以使用Slim读写锁，它针对速度和内存消耗进行了优化。

您应该看看堆栈溢出问题" c++ 11等效于boost shared_mutex"，特别是以下链接的电子邮件对话:http://permalink.gmane.org/gmane.comp.lib.boost.devel/211180(它解释了c++ 11委员会对批准shared_mutex的阻力)。下面是Joe Duffy博客上的实验:http://www.bluebytesoftware.com/blog/2009/02/12/ReaderwriterLocksAndTheirLackOfApplicabilityToFinegrainedSynchronization.aspx.

每次考虑读/写锁时，问自己以下6个问题。如果你对其中任何一个问题的回答都是否定的，那么读/写锁将使你的程序变得更糟，而不是更好。

  1. 我的共享对象是const吗?在我的生活中，shared_mutex的错误用法比正确用法更多。要正确使用shared_mutex，它必须是这样的情况，您可以在reader临界区内声明您的共享对象const而不会引起编译器的任何投诉。"消费者"不是等同于"根本不改变数据结构的人"。
  2. 临界区真的很长吗?锁定shared_mutex比锁定普通互斥锁的代价要高得多。你必须在临界区有大量的工作来弥补锁获取/释放增加的开销。
  3. 我的临界区应该那么长吗?你应该问问自己，你是否真的需要在一个关键区域做所有的工作。通常会有大量的准备工作和/或工作来处理围绕const调用共享对象的返回对象。从第一次使用共享对象到最后一次使用共享对象之间的数据依赖路径上的许多额外工作可以移到临界区之外。
    4. 锁争用真的是我的性能问题吗?即使您的临界区很长，也应该绝对确定锁争用确实是您的性能问题。如果您没有遇到严重的锁争用，那么切换到读/写锁不会给您带来任何好处。我可以通过切换到更细粒度的锁定方案来减少锁争用吗?您是否使用单个锁来保护多个对象?你能给每个对象一个锁吗?
  4. 读写器的比例是否显著大于1:1?即使您的临界区很长并且锁争用是一个严重的问题，读/写的比率也需要非常高才能从读/写锁中获得任何好处。数量取决于硬件上原子指令的成本和特定实现的质量。(Joe Duffy发现，在他的机器上，他需要一个大约20:1的读取器:写入器的比例，才能使读取器/写入器锁定获胜。)
相关文章：