同步互斥机制和编程方法

文章目录

同步互斥机制和编程方法
- 一、前言
- 二、同步互斥机制
- - 2.1 概念回顾
  - 2.2 竞态条件（race condition）
  - - 2.2.1 概述
    - 2.2.2 解决方法
  - 2.3 具体做法及其编程
  - - 2.3.1 忙等互斥
    - 2.3.2 睡眠与唤醒（软硬件结合）
- 三、小结

一、前言

同步互斥到底是怎样产生的呢？我们一起借助编程来探索一下吧~

二、同步互斥机制

2.1 概念回顾

同步：谁先做
比如：编辑器的词频检测
互斥：一个做的时候，另一个不要打扰

2.2 竞态条件（race condition）

2.2.1 概述

两个或多个线程同时对一共享数据进行修改，影响程序运行的正确性。这也是产生同步互斥的原因

2.2.2 解决方法

禁止多个线程同一时刻对共享资源进行读写（不推荐，本质就是实现多个任务互相调度）
共享资源：共享文件、共享内存（多线程易引发冲突）
临界区
- 任何时候两个进程不能同时处于临界区（任何一个任务都只能独占临界区）
- 不应对CPU的速度和数量做任何假设（CPU的速度和数量是随机的，任务执行是随机的）
- 位于临界区外的进程不得阻塞其他进程
- 不能使任何进程无限等待进入临界区

针对上述提出了4个遵循的原则（偏理论性）

遵循的原则

空闲让进：临界区空闲时，应允许一个进程访问
忙则等待：临界区正在被访问时，其他试图访问的进程需要等待
有限等待：要在有限时间内进入临界区，保证不饥饿
让权等待：进不了临界区的进程，要释放处理机，防止忙等
防止轮询耗费资源，纯软不能实现让权

2.3 具体做法及其编程

重要的概念：
阻塞：睡眠（队列维护）
忙等：自旋锁（用户用不到，内核用，内核才知道这个资源是快速设备还是慢速设备）
OS：
正在执行的任务和阻塞的任务抢占CPU
阻塞的任务睡觉去了，等待正在执行的任务执行完唤醒CPU

2.3.1 忙等互斥

在现代OS中，忙等互斥多使用在小时间事件上

屏蔽中断（纯硬件·最直接）
每个进程在进入临界区后立即屏蔽所有中断（但是千万不要忘记打开）
缺点：
- 屏蔽中断时间很长，CPU不能调度，很多任务响应不了
- 如果屏蔽过程中出现错误，但是时钟中断被屏蔽，容易陷入死机
方案的可行性：
- 进程进入临界区是由谁来决定的？
  如果是用户进程，全凭用户意愿，当进程进入临界区后，用户进程关闭中断，如果经过一段较长时间后，进程没有离开，那么中断就一直启动不了，会有什么问题？答：黑客用户就很危险，因此绝对不会开放给用户
  对内核来说，当它执行更新变量或列表的几条指令期间将中断屏蔽是很方便的
- 多核CPU屏蔽中断不可行
  一套汇编指令实现只屏蔽一个CPU，可能会导致其他CPU可以运行，仍然会有冲突
应用：
单核CPU的快速事件
锁变量（纯软件）
锁：
- 自旋锁（spin_lock）：忙等锁，不会放弃CPU，轮询CPU，while()，适合小周期的小等待
- 互斥锁（mutex）：阻塞行为，一旦发现资源不可用，睡眠-放弃CPU，最终还是要获得CPU，被另外的程序断唤醒，CPU调度（睡眠和唤醒会用）
Linux用一般是互斥锁，自旋锁一般是内核用，用户一般用不到
这里的锁变量是指自旋锁
先设置一把锁，锁变量等于0（没锁）。现在，进程A在t时刻时被CPU调度了，这时进程A就先判断一下锁是否等于0（有没有人用），如果等于0（没有人用）马上设置为1，t2时刻，进程B尝试进入临界区了，就循环判断lock等不等于0，while(lock == 1);，红色的阻塞就代表一直轮询CPU，红色和蓝色一直抢CPU（但是分时的话就会都能用得到），一直到进程A离开临界区，lock = 0;进程B立刻设置lock = 1;
编码模拟：
```
intlock=0;// 临界区代码段(外面)externvoidcritical_region();// 非临界区的代码段externvoidnoncritical_region();voidprocess0(){while(1){// 进入临界区// 判断是否有锁，如果没有锁，死循环等待锁被释放while(lock);// 判断：先从内存中取值，边取边判断// 加锁lock=1;critical_region();// 释放锁lock=0;noncritical_region();}}voidprocess1(){while(1){// 进入临界区// 判断是否有锁，如果没有锁，死循环等待锁被释放while(lock);// 加锁lock=1;critical_region();// 释放锁lock=0;noncritical_region();}}
```
缺点：
lock = 0;准备设置为1时，时间片到了，被进程B抢占了lock = 0;也开始设置为1，时间片又到了，大家一运行就会出问题。
原子操作
刚刚写的代码具有原子性（Atomicity）（要不然读完，要不然写完，在读写的过程中是不允许被打断的）怎么实现原子变量？
有些硬件中没有办法实现，早期没有硬件帮忙时，实现原子变量还是得借助内存，这时自旋锁应运而生
怎么实现自旋锁？
封装了两个接口：spin_lock(&lcok);codespin_unlock(&lock);。CPU不支持汇编，直接写的话，关中断，写入or读取，开中断（spin_lock(&lcok);）
虽说是原子性，可以通过关中断的方法实现原子性，原子性的目的就是关中断，现在采用专门的指令集（TSL）：测试并设置、比较并交换（软件靠不了，只能靠硬件），接口还是不变

严格轮询法（纯软件)

单标志法轮询方式

编码模拟：

intturn;// 表示当前允许进入临界区的进程号// 临界区代码段(外面)externvoidcritical_region();// 非临界区的代码段externvoidnoncritical_region();voidprocess0(){while(1){// 准备进入临界区，轮询判断当前进程能否进入while(turn==0){// 执行临界区critical_region();turn=1;// 标记当前可以进入临界区的是进程1noncritical_region();}}}voidprocess1(){while(1){// 准备进入临界区，轮询判断当前进程能否进入while(turn==1){// 执行临界区critical_region();turn=0;// 标记当前可以进入临界区的是进程1noncritical_region();}}}

turn等于谁谁就能运行

缺点：

进程1执行完，就会出现进入非临界区等待（时间很长），这时运行进程2，但是进程2非常快，执行完毕后，仍然还是进程1在非临界区，这时候就不能再进入进程2，违背了“空闲让进”原则

Peterson解法（纯软件）

类型：

谦让型
主动争取，主动谦让，检查，且最好后一次是谁谦让
主动自信型
一般不用

编码模拟：

#defineFALSE0#defineTRUE1// 临界区代码段(外面)externvoidcritical_region();// 非临界区的代码段externvoidnoncritical_region();intturn;// 记录当前“轮到”哪个进程进入临界区intinterested[2];// 记录每个进程是否愿意进入临界区voidenter_region(intprocess){intother=1-process;// 进程编号就是0或1interested[process]=TRUE;// 标记本进程希望进入临界区turn=other;// 尝试将turn设置为另一个进程的编号// 等待条件：检查对方是否也想使用，且最后一次是谦让的（就代表谁最后执行）while(interested[other]==TRUE&&turn==other);}voidleave_region(intprocess){// 标记本进程已经离开临界区interested[process]=FALSE;}voidprocess0(){do{enter_region(0);critical_region();leave_region(0);noncritical_region();}while(TRUE);}voidprocess1(){do{enter_region(1);critical_region();leave_region(1);noncritical_region();}while(TRUE);}

遵循空闲让进、忙则等待、有限等待，未遵循让权等待

TSL指令、XCHG指令（纯硬件）
纯靠硬件实现锁的问题，都是原子操作，可以实现多CPU操作
TSL
- 读取与锁定
  指令从指定的内存中读取当前值，将这个值加载到寄存器RX中，若0，在内存里写1，加锁；否则一直读，然后进入临界区干活，干完释放锁，归0
XCHG：主要是x86使用
交换寄存器和内存位置，在寄存器放1，将寄存器中的1给lock，lock原来的值给寄存器（lock永远等于1），检查寄存器的值（判断锁是否被设置），如果不等于0，继续尝试enter_region，成功取锁后，进入临界区执行代码，执行完离开临界区，释放锁