CHS_04.2.3.3+互斥锁

CHS_04.2.3.3+互斥锁

  • 进程互斥:锁

接下来 用于实现互斥的一种方法 你可以简单理解为 锁就是一个bool的变量

进程互斥:锁

CHS_04.2.3.3+互斥锁_第1张图片

只有true和false或者零和一两种状态分别表示当前已上锁或者没有上锁

有这样的两个函数可以操作锁acquire 这个函数就是上锁获得 锁

而release可以释放锁 那用锁实现互斥的主要缺点就是忙等

如果进不了临界区 就会不断的外物循环被卡在这忙等 这就会导致cpu资源的浪费 违反了让权等待的原则

由于忙等的过程中需要不断的循环检查 因此这类的锁通常把称为自旋锁

自己在原地旋转跳跃 闭着眼 像 我们之前学过tsl指令 swap指令以及单标志法

这些都属于自旋锁 那无论是哪种自旋锁 总之都是用于解决进程互斥的问题的

同时 锁有的这些自旋锁包括这介绍的互斥锁都有忙等的问题 都违反了让权等待的原则

那值得一提的是 如果一个进程在忙等暂时进不了临界区 那么他并不会一直占用处理机

如果这个进程它的时间片用完 那调度程序依然会让它下处理机 所以并不是忙等 就会一直占用处理机 它的时间片还是会用完的

那这种忙等的特性其实也有它的优点 因为在等待锁的期间不需要切换进程的上下文 切换进程的上下文其实

大家还是蛮大的 对吧 所以在多处理器的系统当中 如果对临界区上锁的时间很短

那么 这种自旋等待其实代价反而会很低 在多处理器的系统当中

如果某一个进程p一此时正在自旋等待 那么他只会吃掉这一个核的一个计算能力

那如果此时上锁的进程p二也在某一个核心里面运行 那p二是不是很有可能在接下快速的使用好临界区 然后快速的解锁

解锁了之后 这个p一在自旋等待的过程当中是不是突然就会发现哦 解锁了那他是不是就可以顺利的进入临界区

而这个自旋忙等的过程由于没有发生进程切换 因此忙等的代价反而是很低的

所以自旋锁的这种策略通常会用于多处理器的系统当中一个核 此时可能它的运算能力会被吃掉 在忙等

但其他核可以照常工作并且快速的释放 临界区正自旋锁就不太适用于单处理机系统

因为如果是单处理机系统的话 p一进程 此时他吃掉了唯一一个核 对吧 他在这个时间片的有可能等到被解锁吗 不可能

只有他这个时间片用完并且上锁的那个进程上处理机然后解锁之后

他才有可能获得这个锁 所以在单处理机系统当中 他不可能说这个自旋等着等着 哎 突然就获得锁了 不会发生这种情况
CHS_04.2.3.3+互斥锁_第2张图片

因此 这样自旋锁更适用于多处理机的系统好 这就是新考点锁用于实现进程互斥

推荐一个零声学院免费公开课程,个人觉得老师讲得不错,分享给大家:Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK等技术内容,立即学习

你可能感兴趣的:(操作系统,#,03.2.3,同步与互斥,第二章进程与线程,服务器,linux,数据库,操作系统)