首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >问答首页 >我是否不想使用读/写锁而不是普通的互斥锁?

我是否不想使用读/写锁而不是普通的互斥锁?
EN

Stack Overflow用户
提问于 2016-09-14 17:36:03
回答 2查看 1.4K关注 0票数 6

当同步访问共享资源时,是否有理由不使用读/写锁而不是普通的互斥锁(这基本上只是一个写锁),除了它具有比我可能需要的更多特性的哲学原因吗?

换句话说,如果我只是默认地将读/写锁作为我首选的同步结构,那么我是在朝自己开枪吗?

在我看来,总是选择读/写锁并相应地使用读/写锁的一个很好的理由是,我可以实现一些同步,如果有一天我将代码放到一个更高争用的环境中,那么我就不必再考虑它,同时获得更好的性能可伸缩性的好处。因此,假设它在没有实际成本的情况下有潜在的好处,那么一直使用它是有意义的。这有意义吗?

这是在一个资源有限的系统上,它可能更多的是一个性能问题。此外,我已经概括了这个问题,但我特别想到了Qt的QReadWriteLockQMutex (C++),如果这很重要的话。

EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2016-09-14 18:16:03

实际上,读/写锁对中的写锁比简单的互斥锁要昂贵得多。读/写锁总是有一些协调策略,在获取或释放锁时必须应用这些策略。根据具体的实现情况,这种策略可以是廉价的,也可以是昂贵的,但它总是存在的。

QReadWriteLock的情况下,有一些逻辑赋予作者优先权。尽管这种逻辑的实现可能是有效的,而且等待队列中没有读者,但它从来都不是完全免费的。

我不太熟悉QMutexQReadWriteLock实现的所有细节,但文档指出,QMutex是针对非竞争情况进行了大量优化的。QReadWriteLock没有这样的评论。也许是因为他们忘了做这样的事,但也许是因为在这种情况下,它的行为不如QMutex那么好。

我认为,在最好的情况下,使用读/写锁的代价是可以忽略的。但在最坏的情况下,当你为每一纳秒而战时,它可能是值得注意的。

票数 2
EN

Stack Overflow用户

发布于 2016-09-14 18:05:20

它确实归结为你的锁堵塞的特点。如果简单互斥对象表现得更好,则会出现严重的拥塞和作者偏好。

这是一个非常冗长和有争议的问题。我可以推荐自旋锁和读写锁睡眠读写锁读物,这样你才能做出明智的决定吗?

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/39496504

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档