multithreading - 我是否曾经*不想*想使用读/写锁而不是普通的互斥锁？

Question

在同步访问共享资源时，是否有理由不使用读/写锁而不是普通的互斥锁(基本上只是写锁)，除了它具有比我可能需要的更多功能的哲学原因？

换句话说，如果我只是默认使用读/写锁作为我首选的同步结构，我是不是在踢自己？

在我看来，总是选择读/写锁并相应地使用读锁和写锁的一个很好的理由是，我可以实现一些同步，然后在获得更好性能的可能好处的同时永远不必再考虑它如果有一天我把代码放到一个竞争更激烈的环境中，那么将来的可扩展性。因此，假设它具有潜在的好处而没有实际成本，那么一直使用它是有意义的。那有意义吗？

这是在一个并非真正资源有限的系统上，这可能更多是一个性能问题。我也对这个问题进行了概括，但我有 Qt 的 QReadWriteLock和 QMutex (C++) 特别记住，如果它很重要。

Answer 1

实际上，读/写锁对中的写锁比简单的互斥锁更昂贵。读/写锁总是有一些协调策略，当您获​​取或释放锁时必须应用这些策略。根据特定的实现，此策略可能便宜或昂贵，但它始终存在。

如果是 QReadWriteLock ，有一些逻辑优先考虑作家。尽管这种逻辑的实现可能是有效的，并且等待队列中没有读者，但它永远不会完全免费。

我不熟悉 QMutex 的所有细节和 QReadWriteLock实现，但文档说 QMutex针对非争用情况进行了大量优化。 QReadWriteLock没有这样的评论。可能是因为他们忘了做这样的笔记，也可能是因为它在这种情况下的表现不如QMutex .

我认为，在最好的情况下，使用读/写锁的惩罚可以忽略不计。但在最坏的情况下，当你为每一纳秒而战时，它可能会很明显。