当对共享资源进行同步访问时，除了具有比我可能需要的更多的特性之外，是否有不使用读写锁而不是普通互斥锁(基本上只是一个写锁)的理由 ?
换句话说，如果我只是默认读/写锁作为我选择的首选同步结构，我是不是搬起石头砸自己的脚?
在我看来，总是选择读/写锁，并相应地使用读/写锁的一个很好的理由是，我可以实现一些同步，然后不必再考虑它，同时如果有一天我将代码放入更高争用的环境中，在将来获得更好的性能可伸缩性可能带来的好处。因此，假设它有潜在的好处而没有实际成本，那么一直使用它是有意义的。明白了吗?
这是在一个没有真正资源限制的系统上，它可能更多的是一个性能问题。此外，我也提出了这个问题，但我有Qt的QReadWriteLock和QMutex (c++)特别在脑海中，如果它的问题。
在实践中，读写锁对中的写锁比简单的互斥锁更昂贵。读/写锁总是有一些协调策略，在获取或释放锁时必须应用这些策略。根据具体的实现，这个策略可能便宜也可能昂贵，但它总是存在的。
在QReadWriteLock的情况下，有一些逻辑赋予写入者优先权。尽管这种逻辑的实现可能是高效的，并且等待队列中没有读取器，但它永远不会完全空闲。
我不熟悉QMutex和QReadWriteLock实现的所有细节，但是文档说QMutex针对非争用情况进行了大量优化。QReadWriteLock没有这样的评论。也许是因为他们只是忘记做这样的笔记，但也许是因为它在这种情况下的行为不如QMutex好。
我认为，在最好的情况下，使用读/写锁的代价可以忽略不计。但在最糟糕的情况下，当你为每一纳秒而战时，它可能会被注意到。
这实际上归结为锁的拥塞特性。简单互斥锁性能明显更好的情况是写优先级严重拥塞。
这是一个很长很有争议的话题。我可以推荐自旋锁、读写锁和睡眠读写锁阅读吗?这样您就可以做出明智的决定了。