时间戳

首页 > 解决方案 > C++ 中的读锁有什么作用？

c++ - C++ 中的读锁有什么作用？

问题描述

使用 ashared_mutex时，有独占访问和共享访问。独占访问只允许一个线程访问资源，而其他线程被阻塞，直到持有锁的线程释放锁。共享访问是指允许多个线程访问资源但处于“读锁”之下。什么是“读锁”？我不明白读锁的含义。有人可以给出“读锁”的代码示例。

我对读锁的猜测：我认为读锁只允许线程运行代码而不修改任何东西。显然，当我尝试一些代码时我错了，它并没有像我想象的那样工作。

再次，有人可以帮我理解什么是读锁。

谢谢。

标签： c++multithreading

解决方案

您的猜测非常接近正确，但有一点微妙之处。

读/写区别显示了储物柜的意图，它不限制储物柜的实际作用。如果一个读锁者决定修改受保护的资源，它可以，并且会随之而来。但是，这与完全没有锁定修改受保护资源的线程没有什么不同。程序员必须遵守规则，否则就要付出代价。

至于区别，读锁适用于您只想读取共享资源的情况。十亿个不同的线程可以安全地执行此操作，因为在执行此操作时资源不会发生变化。

另一方面，写锁意味着您要更改共享资源，因此不应该有具有活动锁的读取器（或其他写入器）。

这是一种根据使用情况优化锁的方法。例如，考虑下面的锁队列，最早的条目在右边，并且不允许队列跳跃（如果写入器当前被阻塞，则读取器跳到写入器前面）：

(queue here) -> RR W RRRR -> (action here)
  • “资源控制器”可以允许队列头处的所有四个R储物柜同时访问。
  • 然后，W储物柜必须等到所有这些锁都被释放后才能获得访问权限。
  • 最后两个R储物柜必须等到W储物柜释放，然后才能同时获得访问权限。

换句话说，在任何给定时间可能的锁持有者是（互斥的）：

  • 任意数量的读者。
  • 一位作家。

顺便说一句，您还可以使用其他可能的优化策略。

例如（如前所述），如果看起来作者无论如何都必须等待一段时间（例如当前有大量读者），您可能希望读者能够跳队列。

这充满了危险，因为您可能会饿死写锁，但如果队列跳线的数量有限制，则可以这样做。

我过去做过。从内存（很久以前为 6809 CPU 内置 BCPL 的嵌入式操作系统的内存，这表明我的年龄比我可能想要的要多），作者在其锁定请求中包含了它满意的最大队列跳线数量（默认为零），并且未来读者的排队考虑了这一点。

推荐阅读