IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:互斥锁

共 2 篇相关文章

IT 累计浏览 7,501

两个精彩的比喻:吞吐量和延迟、信号量和互斥锁

这篇文章通过两个极其形象的比喻,澄清了计算机领域两对容易混淆的概念:吞吐量与延迟、信号量与互斥锁。 对于吞吐量和延迟,作者用ATM取钱打比方。一个人完成取款的时间是延迟,而整个银行每分钟能服务的人数是吞吐量。比喻生动地说明,增加ATM机数量(提高并行度)可以在延迟不变的情况下大幅提升吞吐量;而取钱后填写问卷(增加串行步骤)则会显著增加延迟,但吞吐量可能保持不变。这清晰地揭示了两者的核心区别:延迟衡量单个任务的体验,吞吐量衡量系统的整体产能。 关于信号量和互斥锁,作者改进了常见的“钥匙”比喻。互斥锁是独占的钥匙,拿到的人拥有唯一打开权。信号量则是一个大公共厕所门口的“可用/已满”指示牌,它代表的是可并发进入的资源数。文章特别指出了原比喻的不足,并用改进后的“牌子”比喻说清了关键差异:二元信号量的牌子(状态标志)可以被任何人翻动,而互斥锁的钥匙只能由拥有者打开。这个细微差别,正对应了状态协作与资源独占的不同使用场景。

IT 累计浏览 2,587

有关读写锁

这篇文章讲的是为什么在并发编程中需要引入读写锁。作者从最基本的互斥锁(Mutex)出发,指出在“读多写少”的场景下,互斥锁会让所有线程串行化,即使多个线程只是读取数据,也无法并行,这严重限制了程序的吞吐量和性能。 核心方案就是读写锁(Read-Write Lock)。文章清楚地解释了它的关键差异:将锁分为“读锁”和“写锁”。多个线程可以同时持有读锁,进行并发读取,实现了真正的读并行;而写锁则是独占的,一旦有线程想写入数据,它必须等待所有读锁和其他写锁被释放。这种设计巧妙地在保证数据一致性(通过写锁的独占性)的同时,最大化地提升了读操作的并发性能。 文章进一步对比了它们的适用场景。互斥锁适合写操作频繁,或者读写耗时都差不多的简单场景。而读写锁则明确针对读远多于写,且读操作耗时较长的应用,例如缓存系统、配置中心或任何读多写少的共享数据结构。理解这一点,就能在性能瓶颈出现时,知道该从哪里优化锁策略。