在同步对共享资源的访问时，除了它具有比我可能需要的更多功能的哲学原因之外，是否有理由不使用读/写锁而不是普通互斥锁（基本上只是一个写锁） ？
换句话说，如果我只是默认将读/写锁作为我首选的同步结构，我是不是在自找麻烦？
在我看来，总是选择读/写锁并相应地使用读与写锁的一个很好的理由是，我可以实现一些同步，然后不必再考虑它，同时获得更好的性能可能带来的好处如果有一天我把代码放到一个竞争更激烈的环境中，未来的可扩展性。因此，假设它具有潜在的好处而没有实际成本，那么一直使用它是有意义的。那有意义吗？
这是在一个没有真正资源限制的系统上，它可能更多的是一个性能问题。此外，我通常已经提出了这个问题，但如果重要的话，我会特别考虑 QtQReadWriteLock和QMutex(C++)。
实际上，读/写锁对中的写锁比简单的互斥锁更昂贵。读/写锁总是有一些协调策略，当您获取或释放锁时必须应用这些策略。根据特定的实现，这种策略可能便宜或昂贵，但它始终存在。
在 的情况下QReadWriteLock，有一些逻辑优先考虑作者。尽管这种逻辑的实现可能很有效，并且等待队列中没有读者，但它永远不会完全免费。
我不熟悉QMutex和QReadWriteLock实现的所有细节，但文档说这QMutex是针对非竞争案例进行了高度优化。QReadWriteLock没有这样的评论。也许是因为他们只是忘了做这样的笔记，但也许是因为它在这种情况下的表现不如QMutex。
我认为，在最好的情况下，使用读/写锁的惩罚可以忽略不计。但在最坏的情况下，当你为每一纳秒而战时，它可能会很明显。
这真的归结为锁的拥塞特征。简单互斥体性能明显更好的情况是写入器偏好的严重拥塞。
这是一个非常冗长且值得商榷的话题。我可以推荐Spinlocks 和 Read-Write Locks和Sleeping Read-Write Locks阅读，以便您做出明智的决定吗？