ado*_*oug 9 language-agnostic performance multithreading mutex readwritelock
当同步对共享资源的访问时，除了它具有比我可能需要的更多功能的哲学原因之外，是否还有理由不使用读/写锁而不使用普通互斥锁（这基本上只是一个写锁） ？
换句话说，如果我只是默认将读/写锁作为我首选的同步结构，我是否会搬起石头砸自己的脚？
在我看来，始终选择读/写锁并相应地使用读锁与写锁的一个很好的理由是我可以实现一些同步，然后永远不必再考虑它，同时获得更好性能的可能好处如果有一天我将代码放入一个竞争更激烈的环境中，那么将来的可扩展性就会增加。因此，假设它有潜在的好处而没有实际成本，那么一直使用它是有意义的。那有意义吗？
这是在一个资源并不真正受限的系统上，这可能更多是一个性能问题。另外，我已经笼统地表达了这个问题，但如果重要的话，我会特别考虑 QtQReadWriteLock和（C++）。QMutex
实际上，读/写锁对中的写锁比简单的互斥体更昂贵。读/写锁总是有一些在获取或释放锁时必须应用的协调策略。根据特定的实现，该策略可能便宜也可能昂贵，但它始终存在。
在 的情况下QReadWriteLock，有一些逻辑优先考虑作者。尽管这种逻辑的实现可能是高效的，并且等待队列中没有读者，但它永远不会完全免费。
QMutex我不熟悉和实现的所有细节QReadWriteLock，但文档说它QMutex针对非竞争情况进行了大力优化。QReadWriteLock没有这样的言论。也许是因为他们只是忘了做这样的注释，但也许是因为它在这种情况下的表现不如QMutex。
我认为，在最好的情况下，使用读/写锁的惩罚可以忽略不计。但在最坏的情况下，当你为每一纳秒而战时，它可能会很明显。