我想使用新的标准线程而不是 boost:threads 但我注意到旧的 shared_mutex 不可用。替换此功能并给我一个多读取器、单写入器锁的好建议是什么？
问问题
23078 次
2 回答
24
std::shared_mutex将成为 C++14 标准库的一部分。它没有进入 C++11 只是因为没有时间制定提案并彻底讨论。
你仍然可以使用boost::shared_mutex。在 Windows 下，如果您使用的是 Windows Vista 或更高版本，则可以使用针对速度和内存消耗进行了优化的Slim 读写锁。
于 2013-05-27T13:38:07.320 回答
16
您应该查看堆栈溢出问题“ 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 个问题。如果您可以对其中任何一个回答“否”，那么读/写锁将使您的程序变得更糟，而不是更好。
- 是我的共享对象
const吗？在我的生活中，我看到的不正确的用法shared_mutex比正确的用法要多。要shared_mutex正确使用 a ，您必须可以const在阅读器关键部分内声明共享对象，而不会引起任何编译器投诉。“消费者”不等同于“根本不改变数据结构的人”。 - 我的关键部分真的很长吗？锁定一个 shared_mutex比锁定一个常规的互斥锁要昂贵得多。你必须在你的关键部分做很多工作来弥补锁获取/释放增加的开销。
- 我的关键部分应该那么长吗？您应该问自己是否真的需要在关键部分完成所有这些工作。通常有一堆准备工作和/或工作来按摩围绕
const对共享对象的调用的返回对象。从第一次使用共享对象到最后一次使用共享对象的数据依赖路径之外的大部分额外工作都可以移到临界区之外。 - 锁争用真的是我的性能问题吗？即使您的关键部分很长，您也应该绝对确定锁争用确实是您的性能问题。如果您没有遇到严重的锁争用，那么切换到读取器/写入器锁不会给您带来任何好处。
- 我可以通过切换到更细粒度的锁定方案来减少锁定争用吗？您是否使用单个锁来保护多个对象？你能给每个对象一个自己的锁吗？
- 读者与作者的比例是否显着大于 1:1？即使您的关键部分很长并且锁争用是一个严重的问题，读者与作者的比率也需要非常高才能从读/写锁中获得任何好处。数量取决于硬件上原子指令的成本和特定实现的质量。（Joe Duffy 发现在他的机器上，他需要大约 20:1 的读取器：写入器比率才能使读取器/写入器锁定胜出。）
于 2013-05-27T16:19:21.097 回答