我是否不想使用读/写锁而不是普通的互斥锁？
当同步访问共享资源时，是否有理由不使用读/写锁而不是普通的互斥锁(这基本上只是一个写锁)，除了它具有比我可能需要的更多特性的哲学原因吗？
换句话说，如果我只是默认地将读/写锁作为我首选的同步结构，那么我是在朝自己开枪吗？
在我看来，总是选择读/写锁并相应地使用读/写锁的一个很好的理由是，我可以实现一些同步，如果有一天我将代码放到一个更高争用的环境中，那么我就不必再考虑它，同时获得更好的性能可伸缩性的好处。因此，假设它在没有实际成本的情况下有潜在的好处，那么一直使用它是有意义的。这有意义吗？
这是在一个资源有限的系统上，它可能更多的是一个性能问题。此外，我已经概括了这个问题，但我特别想到了Qt的QReadWriteLock和QMutex (C++)，如果这很重要的话。
回答 2
Stack Overflow用户
发布于 2016-09-14 10:16:03
实际上，读/写锁对中的写锁比简单的互斥锁要昂贵得多。读/写锁总是有一些协调策略，在获取或释放锁时必须应用这些策略。根据具体的实现情况，这种策略可以是廉价的，也可以是昂贵的，但它总是存在的。
在QReadWriteLock的情况下，有一些逻辑赋予作者优先权。尽管这种逻辑的实现可能是有效的，而且等待队列中没有读者，但它从来都不是完全免费的。
我不太熟悉QMutex和QReadWriteLock实现的所有细节，但文档指出，QMutex是针对非竞争情况进行了大量优化的。QReadWriteLock没有这样的评论。也许是因为他们忘了做这样的事，但也许是因为在这种情况下，它的行为不如QMutex那么好。
我认为，在最好的情况下，使用读/写锁的代价是可以忽略的。但在最坏的情况下，当你为每一纳秒而战时，它可能是值得注意的。
https://stackoverflow.com/questions/39496504
复制
![[Java 并发]读锁/写锁](https://ask.qcloudimg.com/http-save/yehe-4201576/fmcdrb4qxe.png)
腾讯云开发者
