22-2进程与线程(同步与互斥)
同步与互斥
并发执行的进程以各自独立的、不可预知的速度向前推进，即进程具有异步性，操作系统需要提供进程同步机制来解决异步问题
- 同步也称直接制约关系，指为完成某种任务而建立的两个或多个进程，这些进程在某些位置上协调他们的工作次序而产生的制约关系。进程间的直接制约关系就是源于它们之间的相互合作
- 如，管程的读进程、写进程并发运行，由于并发必然导致异步性，写数据和读数据两个操作执行的先后顺序是不确定的
- 实际应用中，又必须按照写数据 -> 读数据的顺序来执行，进程同步就是解决这样的情况
进程的并发需要共享的支持。各个并发执行的进程不可避免的需要共享一些系统资源（比如内存，又比如打印机、摄像头这样的I/O设备），资源共享方式分为以下两种
- 互斥共享方式：
- 系统中的某些资源，虽然可以提供给多个进程使用，但一个时间段内只允许一个进程访问该资源
- 同时共享方式：
- 系统中的某些资源，允许一个时间段内由多个进程"同时"对它们进行访问
进程互斥指当一个进程访问某临界资源时，另一个想要访问该临界资源的进程必须等待
- 临界资源：一个时间段内只允许一个进程使用的资源
- 如物理设备（比如摄像头、打印机）、变量、数据、内存缓冲区等
- 对临界资源的访问，必须互斥地进行。互斥，亦称间接制约关系。当前访问临界资源的进程访问结束，释放该资源之后，另一个进程才能去访问临界资源
对临界资源的互斥访问，可以在逻辑上分为如下四个部分：
- 进入区：负责检查是否可进入临界区，若可进入，则应设置正在访问临界资源的标志（可理解为"上锁"），以阻止其他进程同时进入临界区
- 临界区：访问临界资源的那段代码
- 退出区：负责解除正在访问临界资源的标志（可理解为"解锁"）
- 剩余区：做其他处理
临界区是进程中访问临界资源的代码段。进入区和退出区是负责实现互斥的代码段。临界区也可称为"临界段"
为了实现对临界资源的互斥访问，同时保证系统整体性能，需要遵循以下原则：
- 空闲让进:
- 临界区空闲时，可以允许一个请求进入临界区的进程立即进入临界区
- 忙则等待:
- 当已有进程进入临界区时，其他试图进入临界区的进程必须等待
- 有限等待：
- 对请求访问的进程，应保证能在有限时间内进入临界区（保证不会饥饿）
- 让权等待：
- 当进程不能进入临界区时，应立即释放处理机，防止进程忙等待
进程互斥的实现方法
进程互斥可通过软件/算法实现，也可通过硬件实现
进程互斥软件实现：
单标志法
- 算法思想：
- 两个进程在访问完临界区后会把使用临界区的权限转交给另一个进程，也就是说每个进程进入临界区的权限只能被另一个进程赋予
- 即在进入区只做"检查"，不"上锁"，在退出区既给另一个进程"解锁"，又给自己"上锁"
- turn 的初值为0，即刚开始只允许0 号进程进入临界区。
- 若P1 先上处理机运行，则会一直卡在⑤。直到P1 的时间片用完，发生调度，切换P0 上处理机运行
- 代码①不会卡住P0，P0 可以正常访问临界区，在P0 访问临界区期间即时切换回P1，P1依然会卡在⑤。
- 只有P0 在退出区将turn 改为1 后，P1才能进入临界区
- 特点：
- 只能按P0 -> P1 -> P0 -> P1 ->......这样轮流访问
- 这种必须"轮流访问"带来的问题是，如果此时允许进入临界区的进程是P0，而P0 一直不访问临界区，那么虽然此时临界区空闲，但是并不允许P1 访问
- 因此，单标志法存在的主要问题是：违背"空闲让进"原则
双标志先检查线
- 算法思想：
- 设置一个布尔型数组flag[]，数组中各个元素用来标记各进程想进入临界区的意愿
- 比如"flag[0] = ture"意味着0 号进程P0 现在想要进入临界区
- 每个进程在进入临界区之前先检查当前有没有别的进程想进入临界区，如果没有，则把自身对应的标志flag[i] 设为true，之后开始访问临界区
- 即，在进入区先"检查"后"上锁"，退出区"解锁"
- 设置一个布尔型数组flag[]，数组中各个元素用来标记各进程想进入临界区的意愿
- 若按照①⑤②⑥③⑦....的顺序执行，P0 和P1 将会同时访问临界区。
- 特点：
- 双标志先检查法的主要问题是：违反"忙则等待"原则
- 原因在于，进入区的"检查"和"上锁"两个处理不是一气呵成的。"检查"后，"上锁"前可能发生进程切换
双标志后检查法
- 算法思想：
- 双标志先检查法的改版
- 在进入区先"加锁"后"检查"，退出区"解锁"
- 若按照①⑤②⑥....的顺序执行，P0 和P1 将都无法进入临界区
- 特点：
- 双标志后检查法虽然解决了"忙则等待"的问题，但是又违背了"空闲让进"和"有限等待"原则，会因各进程都长期无法访问临界资源而产生"饥饿"现象
- 两个进程都争着想进入临界区，但是谁也不让谁，最后谁都无法进入临界区
Peterson算法
- 算法思想：
- 结合双标志法、单标志法的思想
- 如果双方都争着想进入临界区，那可以让进程尝试"孔融让梨"（谦让）。做一个有礼貌的进程
- 特点：
- Peterson 算法用软件方法解决了进程互斥问题，遵循了空闲让进、忙则等待、有限等待三个原则，但是依然未遵循让权等待的原则
- Peterson 算法相较于之前三种软件解决方案来说，是最好的，但依然不够好
进程互斥硬件实现
中断屏蔽方法：
- 使用"开/关中断"指令实现互斥
- 与原语的实现思想相同，即在某进程开始访问临界区到结束访问为止都不允许被中断，也就不能发生进程切换，因此也不可能发生两个同时访问临界区的情况
- 优点：
- 简单、高效
- 缺点：
- 不适用于多处理机
- 只适用于操作系统内核进程，不适用于用户进程
- 因为开/关中断指令只能运行在内核态，这组指令如果能让用户随意使用会很危险
TestAndSet指令：
- 简称TS指令，也有地方称为TestAndSetLock指令，TSL指令
- TSL 指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成
//布尔型共享变量lock表示当前临界区是否被加锁
//true表示已加锁，false表示未加锁
bool TestAndSet(bool *lock){
bool old;
old=*lock; //old用来存放lock原来的值
*lock=true; //无论之前是否已加锁，都将lock设为true
return old; //返回lock原来的值
}
//使用TSL指令实现互斥的算法逻辑
void main(){
while(TestAndSet(&lock)); //上锁并检查
//临界区代码段...
lock = false; //解锁
//剩余区代码段...
}
- 若刚开始lock 是false，则TSL 返回的old 值为false，while 循环条件不满足，直接跳过循环，进入临界区
- 若刚开始lock 是true，则执行TLS 后old 返回的值为true，while 循环条件满足，会一直循环，直到当前访问临界区的进程在退出区进行"解锁"
- 相比软件实现方法，TSL 指令把"上锁"和"检查"操作用硬件的方式变成了一气呵成的原子操作
- 优点：
- 实现简单，无需像软件实现方法那样严格检查是否会有逻辑漏洞
- 适用于多处理机环境
- 缺点：
- 不满足"让权等待"原则，暂时无法进入临界区的进程会占用CPU并循环执行TSL指令，从而导致"忙等"
Swap指令：
- 有的地方也叫Exchange 指令，XCHG指令
- Swap 指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成
//Swap指令的作用是交换两个变量的值
Swap(bool *a,bool* b){
bool temp;
temp=*a;
*a=*b;
*b=temp;
}
//Swap指令实现互斥逻辑
//lock表示当前临界区是否加锁
void main(){
bool old = true;
while(old == true){
Swap(&lock,&old);
}
//临界区代码段...
lock = false;
//剩余区代码段...
}
- 逻辑上来看Swap 和TSL 并无太大区别，都是先记录下此时临界区是否已经被上锁（记录在old 变量上），再将上锁标记lock 设置为true，最后检查old
- 如果old 为false 则说明之前没有别的进程对临界区上锁，则可跳出循环，进入临界区
- 优点：
- 实现简单，无需像软件实现方法那样严格检查是否会有逻辑漏洞
- 适用于多处理机环境
- 缺点：
- 不满足"让权等待"原则，暂时无法进入临界区的进程会占用CPU并循环执行TSL指令，从而导致"忙等"
互斥锁
互斥锁，mutex lock：
- 解决临界区最简单的工具
- 一个进程在进入临界区时应获得锁；在退出临界区时释放锁
- 函数acquire()获得锁，函数release()释放锁
- 每个互斥锁有一个布尔变量available，表示锁是否可用
- 如果锁是可用的，调用acquire()会成功，且锁不可再用
- 当一个进程试图获取不可用的锁，会被阻塞，知道锁被释放
- 函数acquire()、函数release()的执行必须是原子操作，因此互斥锁通常采用硬件机制实现
- 需要连续循环忙等的互斥锁都可以称为自旋锁spin lock，如TSL指令，swap指令，单标志法
- 特点：
- 等待期间不用切换进程上下文，多处理器系统中，若上锁时间短，等待代价很低
- 常适用于多处理器系统，一个核忙等，其他核照常工作，并快速释放临界区
- 忙等待，进程时间片用完才下处理机，违反让权等待
- 当一个进程在临界区中，任何其他进程在进入临界区时必须连续循环调用acquire()
- 当多个进程共享同个CPU时，就浪费了CPU周期，因此互斥锁通常用于多处理系统，一个线程可在一个处理器上等待，不影响其他线程的执行
- 不适用于单处理机系统，忙等过程不可能解锁
信号量
之前提到进程互斥都存在一系列的问题：
- 双标志位先检查法，进入区的"检查"、"上锁"的操作无法一气呵成，从而导致了两个进程有可能同时进入临界区的问题
- 进程互斥的四种软件实现方式、三种硬件实现方式均无法实现"让群等待"
1965年，荷兰学者Dijkstra提出了一种卓有成效的实现进程互斥、同步的方法：信号量机制
- 用户进程可以通过使用操作系统提供的一对原语来对信号量进行操作，从而很方便的实现了进程互斥、进程同步
- 信号量其实就是一个变量 ，可以用一个信号量来表示系统中某种资源的数量
- 比如：系统中只有一台打印机，就可以设置一个初值为1 的信号量
- 原语是由关中断/开中断指令实现的，用于保证语句段执行的不可被中断
- 信号量其实就是一个变量 ，可以用一个信号量来表示系统中某种资源的数量
- 使用wait(S)、signal(S)原语，S表示信号量
- wait、signal原语常简称为P、V操作，可写作P(S)、V(S)
- 可以把原语理解为我们自己写的函数，函数名分别为wait和signal，括号里的信号量S 其实就是函数调用时传入的一个参数
整型信号量：
- 用一个整数型的变量作为信号量，用来表示系统中某种资源的数量
- 与普通整数变量不同，对整型信号量的操作只有三种，即初始化、P操作、V操作
假设某计算机系统中由一台打印机，用整型信号量实现互斥
- 与普通整数变量不同，对整型信号量的操作只有三种，即初始化、P操作、V操作
int S=1; //初始化整型信号量S，表示当前系统中可用的打印机资源数
void wait(int S){ //wait原语，相当于"进入区"
while(S <= 0); //如果资源数不够，就一直循环等待
S=S-1; //如果资源数够，则占用一个资源
}
void signal(int S){ //signal原语，相当于"退出区"
S=S+1; //使用完整资源后，在退出区释放资源
}
//整型信号量实现互斥过程
//进程P0
void P0{
//P0其他功能代码段...
wait(S); //进入区，申请资源
//使用打印机资源... //临界区，访问资源
signal(S); //退出区，释放资源
//P0其他功能代码段...
}
//进程P1
void P1{
//P1其他功能代码段...
wait(S); //进入区，申请资源
//使用打印机资源... //临界区，访问资源
signal(S); //退出区，释放资源
//P1其他功能代码段...
}
- 优点：
- 整型信号量将检查、上锁一气呵成，避免了并发、异步导致的问题
- 缺点：
- 不满足让权等待原则，会发生忙等
记录型信号量：
- 整型信号量的缺陷是存在"忙等"问题，因此人们又提出了"记录型信号量"，即用记录型数据结构表示的信号量
//记录型信号量数据结构
typedef struct{
int value; //剩余资源数
struct process *L; //等待队列
} semaphone;
//某进程需要使用资源时，通过wait语言申请
void wait(semaphone S){
S.value--;
if(S.value <0){
block(S.L);
}
}
//进程使用完资源后，通过signal原语释放
void signal(semaphone S){
S.value++;
if(S.value <=0){
wakeup(S.L);
}
}
- 如果剩余资源数不够，使用block原语使进程从运行态进入阻塞态，并把挂到信号量S 的等待队列（即阻塞队列）中
- 释放资源后，若还有别的进程在等待这种资源，则使用wakeup 原语唤醒等待队列中的一个进程，该进程从阻塞态变为就绪态
在考研题目中wait(S)、signal(S) 也可以记为P(S)、V(S)，这对原语可用于实现系统资源的"申请"和"释放"
- S.value 的初值表示系统中某种资源的数目
- 对信号量S 的一次P 操作意味着进程请求一个单位的该类资源，因此需要执行S.value--，表示资源数减1
- 当S.value < 0 时表示该类资源已分配完毕，因此进程应调用block 原语进行自我阻塞（当前运行的进程从运行态 -> 阻塞态），主动放弃处理机，并插入该类资源的等待队列S.L 中
记录型信号量机制遵循了"让权等待"原则，不会出现"忙等"现象
- 对信号量S 的一次V 操作意味着进程释放一个单位的该类资源，因此需要执行S.value++，表示资源数加1
- 若加1后仍是S.value <= 0，表示依然有进程在等待该类资源，因此应调用wakeup 原语唤醒等待队列中的第一个进程（被唤醒进程从阻塞态 -> 就绪态）
信号量机制
一个信号量对应一种资源，信号量的值表示这种资源的剩余数量
- 信号量的值如果小于0，说明此时有进程在等待这种资源
- P(S)：申请一个资源S，如果资源不够就阻塞等待
- V(S)：释放一个资源S，如果有进程在等待该资源，则唤醒一个进程
PV操作题目分析步骤：
- 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系
- 整理思路。根据各进程的操作流程确定P、V操作的大致顺序
- 设置信号量。并根据题目条件确定信号量初值（互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少）
信号量实现进程互斥
信号量进程互斥过程：
- 分析并发进程的关键活动，划定临界区
- 如：对临界资源打印机的访问就应放在临界区
- 设置互斥信号量mutex，初值为1。信号量的值表示进入临界区的名额
- 在进入区P(mutex)，申请资源
- 在退出区V(mutex)，释放资源
//信号量机制实现互斥
semaphone mutex=1; //初始化信号量
P1(){
//...
P(mutex); //使用临界资源前需要加锁
//临界区代码段...
V(mutex); //使用临界资源后需要解锁
//...
}
P2(){
//...
P(mutex);
//临界区代码段...
V(mutex);
//...
}
注：
- 对于不同的临界资源需要设置不同的互斥信号量
- P、V操作必须成对出现，缺少P(mutex)就不能保证临界资源的互斥访问，缺少V(mutex)会导致资源永不被释放，等待进程永不被唤醒
- 考试中如没有特殊说明，信号量定义可以直接写初始化语句即可。如需要自行定义，按照题目要求可参考如下格式
//记录型信号量定义
typedef struct{
int value;
struct process *L;
} semaphone;
//信号量简明定义只需写该语句
semaphone mutex =1;
信号量实现进程同步
信号量进程同步过程:
- 分析什么地方需要实现"同步关系"，即必须保证"一前一后"执行的两个操作（或两句代码）
- 设置同步信号量S, 初始为0
- 在"前操作"之后执行V(S)
- 在"后操作"之前执行P(S)
前V后P
假设P1、P2并发执行，要求P2的代码4要基于P1的代码1和代码2的运行结果才能执行，则需要保证代码4一定要在代码2之后才会执行
//信号量机制实现互斥
semaphone S=0; //初始化信号量
P1(){
//代码1
//代码2
V(S);
//代码3
}
P2(){
P(S);
//代码4
//代码5
//代码6
}
- 信号量S代表"某种资源"，刚开始是没有这种资源的。P2需要使用这种资源，而又只能由P1产生这种资源
- 若先执行到V(S) 操作，S++ 后S=1
- 之后当执行到P(S) 操作时，由于S=1，表示有可用资源，会执行S--，S 的值变回0，P2 进程不会执行block 原语，而是继续往下执行代码4
- 若先执行到P(S) 操作
- 由于S=0，S-- 后S=-1，表示此时没有可用资源，P操作中会执行block 原语，主动请求阻塞
- 之后当执行完代码2，继而执行V(S) 操作，S++，使S 变回0
- 由于此时有进程在该信号量对应的阻塞队列中，因此会在V操作中执行wakeup 原语，唤醒P2 进程。这样P2 就可以继续执行代码4 了
信号量实现前驱关系
进程P1 中有句代码S1，P2 中有句代码S2 ，P3中有句代码S3 ...... P6 中有句代码S6。这些代码要求按如下前驱图所示的顺序来执行：
- 每一对前驱关系都是一个进程同步问题，信号量实现前驱关系过程：
- 要为每一对前驱关系各设置一个同步信号量
- 在"前操作"之后对相应的同步信号量执行V 操作
- 在"后操作"之前对相应的同步信号量执行P 操作
P1(){ S1; V(a); V(b); }
P2(){ P(a); S2; V(c); V(d); }
P3(){ P(b); S3; V(g); }
P4(){ P(c); S4; V(e); }
P5(){ P(d); S5; V(f); }
P6(){ P(e); P(f); P(g); S6; }
生产者-消费者问题
问题描述：
- 系统中有一组生产者进程和一组消费者进程，生产者进程每次生产一个产品放入缓冲区，消费者进程每次从缓冲区中取出一个产品并使用
- 注：这里的"产品"理解为某种数据
- 生产者、消费者共享一个初始为空、大小为n的缓冲区
- 只有缓冲区没满时，生产者才能把产品放入缓冲区，否则必须等待
- 只有缓冲区不空时，消费者才能从中取出产品，否则必须等待
- 缓冲区是临界资源，各进程必须互斥地访问
问题分析：
- 初始状态空闲缓冲区的数量为n，非空闲缓冲区(产品)的数量为0
- 同步关系1：缓冲区满时，生产者要等待消费者取走产品
- 同步关系2：缓冲区空时（即没有产品时），消费者要等待生产者放入产品
- 互斥关系：缓冲区不能同时使用
- 总结：
- 生产者每次要消耗（P）一个空闲缓冲区，并生产（V）一个产品
- 消费者每次要消耗（P）一个产品，并释放一个空闲缓冲区（V）
- 往缓冲区放入/取走产品需要互斥
semaphore mutex = 1; //互斥信号量，实现对缓冲区的互斥访问
semaphore empty = n; //同步信号量，表示空闲缓冲区的数量
semaphore full = 0; //同步信号量，表示产品的数量，也即非空缓冲区的数量
producer (){
while(1){
生产产品;
P(empty); //(1)，消耗一个空闲缓冲区
P(mutex); //(2)
在缓冲区放置产品;
V(full); //(3)，增加一个产品
V(mutex); //(4)
}
}
consumer (){
while(1){
P(full); //(5)消耗一个产品
P(mutex); //(6)
从缓冲区取出产品;
V(empty); //(7)增加一个空闲缓冲区
V(mutex); //(8)
使用产品;
}
}
- 假设调换P操作的顺序，(1)和(2)互换，(5)和(6)互换
- 若此时缓冲区内已经放满产品，则empty=0，full=n
- 则生产者进程执行
P(mutex)使mutex变为0，再执行P(empty)，由于已没有空闲缓冲区，因此生产者被阻塞 - 由于生产者阻塞，因此切换回消费者进程。消费者进程执行
P(mutex)，由于mutex为0，即生产者还没释放对临界资源的"锁"，因此消费者也被阻塞 - 这就造成了生产者等待消费者释放空闲缓冲区，而消费者又等待生产者释放临界区的情况，生产者和消费者循环等待被对方唤醒，出现"死锁"
- 则生产者进程执行
- 若缓冲区中没有产品，即full=0，empty=n。按(6)-(5)-(2)的顺序执行就会发生死锁。因此，实现互斥的P操作一定要在实现同步的P操作之后
- 若此时缓冲区内已经放满产品，则empty=0，full=n
- 而调换V操作的顺序，不会引起进程阻塞，(3)、(4)顺序随意，(7)、(8)顺序随意
多生产者-多消费者
问题描述：
- 桌子上有一只盘子，每次只能向其中放入一个水果
- 爸爸专向盘子中放苹果，妈妈专向盘子中放橘子，儿子专等着吃盘子中的橘子，女儿专等着吃盘子中的苹果
- 只有盘子空时，爸爸或妈妈才可向盘子中放一个水果
- 仅当盘子中有自己需要的水果时，儿子或女儿可以从盘子中取出水果
问题分析：
- 同步关系：
- 父亲将苹果放入盘子后，女儿才能取苹果
- 母亲将橘子放入盘子后，儿子才能取橘子
- 只有盘子为空时，父亲或母亲才能放入水果
"盘子为空"这个事件可以由儿子或女儿触发，事件发生后才允许父亲或母亲放水果
- 互斥关系：对缓冲区（盘子）的访问要互斥地进行
semaphore mutex = 0; //实现互斥访问盘子（缓冲区）
semaphore apple = 0; //盘子中有几个苹果
semaphore orange = 0; //盘子中有几个橘子
semaphore plate = 1; //盘子中还可以放多少个水果
mother(){
while(1){
拿橘子;
P(plate);
P(metex);
向盘子里放橘子;
V(orange);
V(metex);
}
}
father(){
while(1){
拿苹果;
P(plate);
P(metex);
向盘子里放苹果;
V(apple);
V(metex);
}
}
daughter(){
while(1){
P(apple);
P(metex);
向盘子里放苹果;
V(plate);
V(metex);
吃苹果;
}
}
son(){
while(1){
P(orange);
P(metex);
从盘子里橘子;
V(plate);
V(metex);
吃橘子;
}
}
- 在该问题中，如果不专门设置互斥变量mutex，也不会出现进程同时访问盘子的现象
- 刚开始，儿子、女儿进程即使上处理机运行也会被阻塞。如果刚开始是福清进程线上处理机运行，则父亲
- 本题中的缓冲区大小为1，在任何时刻，apple、orange、plate 三个同步信
号量中最多只有一个是1。因此在任何时刻，最多只有一个进程的P操作不会被阻塞，并顺利地进入临界区，因此缓冲区不需要设置互斥信号量 - 如果缓冲区大小大于1，则必须设置一个专门的互斥信号量，否则就会存在多个进程同时使用一个设备，导致数据覆写
吸烟者问题
问题描述：
- 假设一个系统有三个抽烟者进程和一个供应者进程
- 每个抽烟者不停地卷烟并抽掉它，但是要卷起并抽掉一支烟，抽烟者需要有三种材料：烟草、纸和胶水
- 三个抽烟者中，第一个拥有烟草、第二个拥有纸、第三个拥有胶水
- 供应者进程无限地提供三种材料，供应者每次将两种材料放桌子上，拥有剩下那种材料的抽烟者卷一根烟并抽掉它，并给供应者进程一个信号告诉完成了，供应者就会放另外两种材料再桌上，这个过程一直重复（让三个抽烟者轮流地抽烟）
问题分析：
- 该问题可以抽象为一个生产者-多个消费者问题
- 供应者每次提供2个材料，共有3中组合：烟草+纸、烟草+胶水、纸+胶水。供应者提供不同的材料，分别与不同的抽烟者存在同步关系
- 提供纸+胶水，第一个抽烟者才能抽烟
- 提供烟草+胶水，第二个抽烟者才能抽烟
- 提供烟草+纸，第三个抽烟者才能抽烟
- 互斥关系：提供者与抽烟者对缓冲区(桌子)需要进行互斥
- 由于抽烟者不提供材料，且每次直接将桌上的所有材料拿走，因此桌子容量视为1
- 容量为1，因此可以不使用信号量控制互斥
- 轮流抽烟，因此假设第一个抽烟者开始，可以用变量取模的方式轮流
semaphore offer1 = 0; //桌上组合一的数量
semaphore offer2 = 0; //桌上组合二的数量
semaphore offer3 = 0; //桌上组合三的数量
semaphore finish = 0; //抽烟是否完成
provider(){
int i=0; //用于实现三个抽烟者轮流抽烟
while(1){
siwtch(i){
case 0:
将材料组合1放在桌上;
V(offer1);
break;
case 1:
将材料组合2放在桌上;
V(offer2);
break;
case 2:
将材料组合3放在桌上;
V(offer3);
break;
}
i=(i+1)%3;
P(finish);
}
}
smoker1(){
while(1){
P(offer1);
拿桌上材料组合1;
卷烟;
抽烟;
V(finish);
}
}
smoker2(){
while(1){
P(offer2);
拿桌上材料组合2;
卷烟;
抽烟;
V(finish);
}
}
smoker3(){
while(1){
P(offer2);
拿桌上材料组合1;
卷烟;
抽烟;
V(finish);
}
}
如果一个生产者要胜场多种产品或者引发多种前驱事件，那么各个V操作应该放在各自对应的事件发生之后的位置
读者-写着问题
问题描述：
- 有读者和写者两组并发进程，共享一个文件
- 当两个或两个以上的读进程同时访问共享数据时不会产生副作用
- 若某个写进程和其他进程（读进程或写进程）同时访问共享数据时则可能导致数据不一致的错误
- 因此要求：
- 允许多个读者可以同时对文件执行读操作；
- 只允许一个写者往文件中写信息；
- 任一写者在完成写操作之前不允许其他读者或写者工作；
- 写者执行写操作前，应让已有的读者和写者全部退出
问题分析：
- 互斥关系：
- 文件只有一个
- 读进程与写进程不能同时对文件进行操作，需要进行互斥
- 读进程和写进程互斥的情况下，需要考虑到底哪个优先
- 由于读进程可以多个同时执行，因此如果读进程优先，可能导致写进程饿死
- 读进程访问文件不需要互斥
- 写进程不能同时对一个文件进行操作，需要进行互斥
- 同步关系：不存在同步问题
semaphore file = 1; //用于实现对共享文件的互斥访问
semaphore write = 1; //用于实现"写优先"
int count=0; //记录当前有多少读进程在访问文件
semaphore mutex = 1; //用于保证对count变量的互斥访问
writer(){
while(1){
P(write);
P(file); //写文件前加锁
向文件写数据;
V(file); //写文件后解锁
V(write);
}
}
reader(){
while(1){
P(write); //与写进程争夺优先权
P(mutex); //各个读进程互斥访问count
if(count == 0) //当这是第一个访问文件的读进程
P(file); //读之前加锁，与后续写进程互斥
count++; //访问文件的读进程数+1
V(mutex);
V(write);
读文件;
P(mutex); //各个读进程互斥访问count
if(count == 1) //当这是最后一个访问文件的读进程
V(file); //所有读进程读完解锁
count--; //访问间的读进程数-1
V(mutex);
}
}
结论：
- 在这种算法中，连续进入的多个读者可以同时读文件；
- 写者和其他进程不能同时访问文件；
- 写者不会饥饿，但也并不是真正的"写优先"，而是相对公平的先来先服务原则
有的书上把这种算法称为"读写公平法"
- 读写问题中，设置了计数器count用来记录当前正在访问共享文件的读进程数。因此可以用count 的值来判断当前进入的进程是否是第一个/最后一个读进程，从而做出不同的处理
- 对count 变量的检查和赋值必须保证原子操作，因此也需要用到互斥信号量
哲学家进餐问题
问题描述：
- 一张圆桌上坐着5名哲学家，每两个哲学家之间的桌上摆一根筷子，桌子的中间是一碗米饭
- 哲学家们倾注毕生的精力用于思考和进餐，哲学家在思考时，并不影响他人
- 只有当哲学家饥饿时，才试图拿起左、右两根筷子（一根一根地拿起）
- 如果筷子已在他人手上，则需等待
- 饥饿的哲学家只有同时拿起两根筷子才可以开始进餐，当进餐完毕后，放下筷子继续思考
问题分析：
- 互斥关系：
- 相邻的哲学家对其中间的筷子的访问需要进行互斥
- 同步关系：不存在同步问题
- 虽然不存在明显的同步问题，但是哲学家必须先后拿到两根筷子才能吃饭，即先后占用两个临界资源
- 如果只对每根筷子进行互斥控制，由于筷子数量和哲学家数量相同，可能会出现每个哲学家各拿一根筷子但是无人能进行吃饭的"死锁"现象
- 因此这个问题的关键在于如何避免死锁
- 可以对哲学家进程施加一些限制条件，比如最多允许四个哲学家同时进餐。这样可以保证至少有一个哲学家是可以拿到左右两只筷子的
- 要求奇数号哲学家先拿左边的筷子，然后再拿右边的筷子，而偶数号哲学家刚好相反。用这种方法可以保证如果相邻的两个奇偶号哲学家都想吃饭，那么只会有其中一个可以拿起第一只筷子，另一个会直接阻塞。这就避免了占有一支后再等待另一只的情况
- 仅当一个哲学家左右两支筷子都可用时才允许他抓起筷子
//假定哲学家按0-4编号，哲学家i左边的筷子编号为i，右边的筷子编号为(i+1)%5
//方案一
semaphore chopstick[5]={1,1,1,1,1}; //筷子的互斥访问
semaphore valid=4; //最多同时进餐哲学家数
Pi(){ //i号哲学家的进程
while(1){
P(valid);
P(chopstick[i]); //拿左筷
P(chopstick[(i+1)%5]); //拿右筷
吃饭;
V(chopstick[i]); //放左筷
V(chopstick[(i+1)%5]); //放右筷
V(valid);
思考;
}
}
//方案二
semaphore chopstick[5]={1,1,1,1,1}; //筷子的互斥访问
Pi(){
while(1){
if(i%2 == 0){ //编号奇数先拿左边再拿右边
P(chopstick[i]); //拿左筷
P(chopstick[(i+1)%5]); //拿右筷
}
else{ //编号偶数先拿右边再拿左边
P(chopstick[(i+1)%5]); //拿右筷
P(chopstick[i]); //拿左筷
}
吃饭;
V(chopstick[i]); //放左筷
V(chopstick[(i+1)%5]); //放右筷
思考;
}
}
//方案三
semaphore chopstick[5]={1,1,1,1,1}; //筷子的互斥访问
semaphore mutex = 1; //互斥地取筷子
Pi(){ //i号哲学家的进程
while(1){
P(mutex); //确保拿一双筷子过程互斥
P(chopstick[i]); //拿左筷
P(chopstick[(i+1)%5]); //拿右筷
V(mutex);
吃饭;
V(chopstick[i]); //放左筷
V(chopstick[(i+1)%5]); //放右筷
思考;
}
}
结论：
- 如果这些进程之间只存在互斥关系，且每个进程都需要同时持有两个临界资源，那么就有"死锁"问题的隐患
管程
信号量机制存在的问题在于编写程序困难、易出错。1973年，Brinch Hansen 首次在程序设计语言 (Pascal)中引入了"管程"成分：一种高级同步机制。让程序员写程序时不需要再关注复杂的PV操作
管程是一种特殊的软件模块，有这些部分组成：
- 局部于管程的共享数据结构说明；
- 对该数据结构进行操作的一组过程/函数；
- 对局部于管程的共享数据设置初始值的语句；
- 管程有一个名字
管程的基本特征：
- 局部于管程的数据只能被局部于管程的过程所访问；
- 一个进程只有通过调用管程内的过程才能进入管程访问共享数据；
- 每次仅允许一个进程在管程内执行某个内部过程
因此每时刻只有一个进程访问临界资源，实现了互斥；变量均在管程内部进行访问和操作，同步问题也得到解决
扩展：用管程解决生产者消费者问题
//管程定义，实际是类的定义
mointor ProducerConsumer
condition full,empty; //条件变量用来实现同步/排队
int count=0; //缓冲区中的产品数
void insert(Item item){ //把产品item放入缓冲区
if(count == N)
wait(full);
count++;
insert_item(item);
if(count == 1)
signal(empty);
}
Item remove(){ //从缓冲区中取出一个产品
if(count == 0)
wait(empty);
count--;
if(count == N-1)
signal(full);
return remove_item();
}
end monitor;
//生产者进程
producer(){
while(1){
item = 生产一个产品;
ProducerConsumer.insert(item);
}
}
//消费者进程
consumer(){
while(1){
item = ProducerConsumer.remove();
消费产品item;
}
}
结论：
- 需要在管程中定义共享数据
- 如生产者消费者问题的缓冲区
- 需要在管程中定义用于访问这些共享数据的"入口"——其实就是一些函数
- 如生产者消费者问题中，可以定义一个函数用于将产品放入缓冲区，再定义一个函数用于从缓冲区取出产品
- 只有通过这些特定的"入口"才能访问共享数据
- 管程中有很多"入口"，但是每次只能开放其中一个"入口"，并且只能让一个进程或线程进入
- 如生产者消费者问题中，各进程需要互斥地访问共享缓冲区。管程的这种特性即可保证一个时间段内最多只会有一个进程在访问缓冲区。注意：这种互斥特性是由编译器负责实现的，程序员不用关心
- 可在管程中设置条件变量及等待/唤醒操作以解决同步问题
- 可以让一个进程或线程在条件变量上等待（此时，该进程应先释放管程的使用权，也就是让出"入口"）
- 可以通过唤醒操作将等待在条件变量上的进程或线程唤醒
封装思想：程序员可以用某种特殊的语法定义一个管程（比如: monitorProducerConsumer ...... end monitor;），之后其他程序员就可以使用这个管程提供的特定"入口"很方便地使用实现进程同步互斥了
扩展：Java 中类似于管程的机制
Java 中，如果用关键字 synchronized 来描述一个函数，那么这个函数同一时间段内只能被一个线程调用
static class monitor{
private Item buffer[] = nwe Item[N];
private int count = 0;
public synchronized void insert(Item item){
...
}
}
每次只能有一个线程进入 insert 函数，如果多个线程同时调用 insert 函数，则后来者需要排队等待
死锁
死锁：
- 在并发环境下，各进程因竞争资源而造成的一种互相等待对方手里的资源，导致各进程都阻塞，都无法向前推进的现象
- 发生死锁后若无外力干涉，这些进程都将无法向前推进
死锁、饥饿、死循环的共同点均是进程无法顺利向前推进的现象（故意设计的死循环除外）
| 项目 | 区别 |
|---|---|
| 死锁 | 死锁一定是"循环等待对方手里的资源"导致的，因此如果有死锁现象，那至少有两个或两个以上的进程同时发生死锁。另外，发生死锁的进程一定处于阻塞态 |
| 饥饿 | 可能只有一个进程发生饥饿。发生饥饿的进程既可能是阻塞态(如长期得不到需要的I/O设备)，也可能是就绪态(长期得不到处理机) |
| 死循环 | 可能只有一个进程发生死循环。死循环的进程可以上处理机运行（可以是运行态），只不过无法像期待的那样顺利推进。死锁和饥饿问题是由于操作系统分配资源的策略不合理导致的，而死循环是由代码逻辑的错误导致的。死锁和饥饿是管理者（操作系统）的问题，死循环是被管理者的问题 |
死锁的必要条件：产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发
- 互斥条件：
- 只有对必须互斥使用的资源的争抢才会导致死锁（如哲学家的筷子、打印机设备）
- 像内存、扬声器这样可以同时让多个进程使用的资源是不会导致死锁的（因为进程不用阻塞等待这种资源）
- 不剥夺条件：
- 进程所获得的资源在未使用完之前，不能由其他进程强行夺走，只能主动释放
- 请求和保持条件：
- 进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源又被其他进程占有，此时请求进程被阻塞，但又对自己已有的资源保持不放
- 循环等待条件：
- 存在一种进程资源的循环等待链，链中的每一个进程已获得的资源同时被下一个进程所请求
发生死锁时一定有循环等待，但是发生循环等待时未必死锁（循环等待是死锁的必要不充分条件）
如果同类资源数大于1，则即使有循环等待，也未必发生死锁。但如果系统中每类资源都只有一个，那循环等待就是死锁的充分必要条件了
可能发生死锁的情况：对不可剥夺资源的不合理分配，可能导致死锁
- 对系统资源的竞争：
- 各进程对不可剥夺的资源（如打印机）的竞争可能引起死锁，对可剥夺的资源（CPU）的竞争是不会引起死锁的
- 进程推进顺序非法：
- 请求和释放资源的顺序不当，也同样会导致死锁。例如，并发执行的进程P1、P2 分别申请并占有了资源R1、R2，之后进程P1又紧接着申请资源R2，而进程P2又申请资源R1，两者会因为申请的资源被对方占有而阻塞，从而发生死锁
- 信号量的使用不当也会造成死锁：
- 如生产者-消费者问题中，如果实现互斥的P操作在实现同步的P操作之前，就有可能导致死锁。（可以把互斥信号量、同步信号量也看做是一种抽象的系统资源）
死锁处理策略
预防死锁：静态策略，破坏死锁产生的四个必要条件中的一个或几个
避免死锁：动态策略，用某种方法防止系统进入不安全状态，从而避免死锁（银行家算法）
死锁检测与解除：允许死锁的发生，不过操作系统会负责检测出死锁的发生，然后采取某种措
施解除死锁
其中预防死锁、避免死锁不允许死锁发生；死锁的检测和解除允许死锁发生
预防死锁
破坏互斥条件：
- 如果把只能互斥使用的资源改造为允许共享使用，则系统不会进入死锁状态
- 比如: SPOOLing技术。操作系统可以采用SPOOLing 技术把独占设备在逻辑上改造成共享设备。比如，用SPOOLing技术将打印机改造为共享设备..
- 缺点：
- 并不是所有的资源都可以改造成可共享使用的资源
- 并且为了系统安全，很多地方还必须保护这种互斥性
因此，很多时候都无法破坏互斥条件
破坏不剥夺条件：
- 当某个进程请求新的资源得不到满足时，它必须立即释放保持的所有资源，待以后需要时再重新申请。也就是说，即使某些资源尚未使用完，也需要主动释放，从而破坏了不可剥夺条
- 当某个进程需要的资源被其他进程所占有的时候，可以由操作系统协助，将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级（比如：剥夺调度方式，就是将处理机资源强行剥夺给优先级更高的进程使用）
- 缺点：
- 实现起来比较复杂
- 释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源，如CPU
- 反复地申请和释放资源会增加系统开销，降低系统吞吐量
- 若采用方案一，意味着只要暂时得不到某个资源，之前获得的那些资源就都需要放弃，以后再重新申请。如果一直发生这样的情况，就会导致进程饥饿
破坏请求和保持条件：
- 可以采用静态分配方法，即进程在运行前一次申请完它所需要的全部资源，在它的资源未满足前，不让它投入运行。一旦投入运行后，这些资源就一直归它所有，该进程就不会再请求别的任何资源了
- 缺点：
- 有些资源可能只需要用很短的时间，因此如果进程的整个运行期间都一直保持着所有资源，就会造成严重的资源浪费，资源利用率极低
- 另外，该策略也有可能导致某些进程饥饿
破坏循环等待条件：
- 可采用顺序资源分配法。首先给系统中的资源编号，规定每个进程必须按编号递增的顺序请求资源，同类资源（即编号相同的资源）一次申请完
- 一个进程只有已占有小编号的资源时，才有资格申请更大编号的资源。按此规则，已持有大编号资源的进程不可能逆向地回来申请小编号的资源，从而就不会产生循环等待的现象
- 在任何一个时刻，总有一个进程拥有的资源编号是最大的，那这个进程申请之后的资源必然畅通无阻
- 因此，不可能出现所有进程都阻塞的死锁现象
- 缺点：
- 不方便增加新的设备，因为可能需要重新分配所有的编号；
- 进程实际使用资源的顺序可能和编号递增顺序不一致，会导致资源浪费；
- 必须按规定次序申请资源，用户编程麻烦
避免死锁
安全序列：
- 指如果系统按照这种序列分配资源，则每个进程都能顺利完成
- 只要能找出一个安全序列，系统就是安全状态。安全序列可能有多个
- 如果分配了资源之后，系统中找不出任何一个安全序列，系统就进入了不安全状态
- 这就意味着之后可能所有进程都无法顺利的执行下去
- 如果有进程提前归还了一些资源，那系统也有可能重新回到安全状态，不过我们在分配资源之前总是要考虑到最坏的情况
"银行家算法"的核心思想：
- 如果系统处于安全状态，就一定不会发生死锁
- 如果系统进入不安全状态，就可能发生死锁（处于不安全状态未必就是发生了死锁，但发生死锁时一定是在不安全状态）
- 在资源分配之前预先判断这次分配是否会导致系统进入不安全状态，以此决定是否答应资源分配请求。如果会进
入不安全状态，就暂时不答应这次请求，让该进程先阻塞等待
例题：
- 假设系统中有n 个进程，m 种资源。某进程Pi向系统申请资源，可用一个长度为m的一维数组Request\(_i\)表示本次申请的各种资源量
- 每个进程在运行前先声明对各种资源的最大需求数，则可用一个n*m 的矩阵（可用二维数组实现）表示所有进程对各种资源的最大需求数
- 不妨称为最大需求矩阵Max，Max[i, j] = K 表示进程Pi 最多需要K 个资源Rj
- 同理，系统可以用一个n*m 的分配矩阵Allocation表示对所有进程的资源分配情况。Max – Allocation = Need 矩阵，表示各进程最多还需要多少各类资源
- 另外，还要用一个长度为m的一维数组Available 表示当前系统中还有多少可用资源
- Available = Available - Request\(_i\);
- Allocation[i, j] = Allocation[i, j] + Request\(_i\)[j];
- Need[i, j] = Need[i, j] – Request\(_i\)[j]
| 进程 | 最大需求(Max矩阵) | 已分配(Allocation矩阵) | 最多还需要(Need矩阵) |
|---|---|---|---|
| P0 | (7,5,3) | (2,1,1) | (5,4,2) |
| P1 | (3,2,2) | (2,0,0) | (1,2,2) |
| P2 | (9,0,2) | (3,0,2) | (6,0,0) |
| P3 | (2,2,2) | (2,1,1) | (0,1,1) |
| P4 | (4,3,3) | (0,0,2) | (4,3,1) |
银行家算法预判本次分配是否会导致系统进入不安全状态：
- 如果Request\(_i\)[j]≤Need[i, j] (0≤j≤m)便转向；反之它所需要的资源数已超过它所宣布的最大值，则认为出错
- 如果Request\(_i\)[j]≤Available[j] (0≤j≤m)，便转向③；否则表示尚无足够资源，P\(_i\)必须等待
- 系统试探着把资源分配给进程P\(_i\)，并修改相应的数据（并非真的分配，修改数值只是为了做预判）
- 操作系统执行安全性算法，检查此次资源分配后，系统是否处于安全状态。若安全，才正式分配；否则，恢复相应数据，让进程阻塞等待
总结：
- 银行家算法步骤：
- 检查此次申请是否超过了之前声明的最大需求数
- 检查此时系统剩余的可用资源是否还能满足这次请求
- 试探着分配，更改各数据结构
- 用安全性算法检查此次分配是否会导致系统进入不安全状态
- 安全性算法步骤：
- 检查当前的剩余可用资源是否能满足某个进程的最大需求
- 如果可以，就把该进程加入安全序列，并把该进程持有的资源全部回收
- 不断重复上述过程，看最终是否能让所有进程都加入安全序列
死锁的检测和解除
如果系统中既不采取预防死锁的措施，也不采取避免死锁的措施，系统就很可能发生死锁
死锁检测算法：
- 用于检测系统状态，以确定系统中是否发生了死锁
- 进行死锁检测的前提：
- 用某种数据结构来保存资源的请求和分配信息
- 提供一种算法，利用上述信息来检测系统是否已进入死锁状态
- 如果系统中剩余的可用资源数足够满足进程的需求，那么这个进程暂时是不会阻塞的，可以顺利地执行下去。
- 如果这个进程执行结束了把资源归还系统，就可能使某些正在等待资源的进程被激活，并顺利地执行下去
- 相应的，这些被激活的进程执行完了之后又会归还一些资源，这样可能又会激活另外一些阻塞的进程...
按上述过程分析，最终能消除所有边，就称这个图是可完全简化的。此时一定没有发生死锁（相当于能找到一个安全序列）
- 如果最终不能消除所有边，那么此时就是发生了死锁。最终还连着边的那些进程就是处于死锁状态的进程
死锁检测算法：
- 在资源分配图中，找出既不阻塞又不是孤点的进程Pi，消去它所有的请求边和分配边，使之称为孤立的结点
- 找出一条有向边与它相连，且该有向边对应资源的申请数量小于等于系统中已有空闲资源数量。如图中，R1没有空闲资源，R2有一个空闲资源。若所有的连接该进程的边均满足上述条件，则这个进程能继续运行直至完成，然后释放它所占有的所有资源
- 在图中，P1是满足这一条件的进程结点，于是将P1的所有边消去
- 进程Pi所释放的资源，可以唤醒某些因等待这些资源而阻塞的进程，原来的阻塞进程可能变为非阻塞进程。在图中，P2就满足这样的条件。根据1）中的方法进行一系列简化后，若能消去途中所有的边，则称该图是可完全简化的
死锁定理：如果某时刻系统的资源分配图是不可完全简化的，那么此时系统死锁
死锁解除算法：
- 当认定系统中已经发生了死锁，利用该算法可将系统从死锁状态中解脱出来
- 一旦检测出死锁的发生，就应该立即解除死锁
- 并不是系统中所有的进程都是死锁状态，用死锁检测算法化简资源分配图后，还连着边的那些进程就是死锁进程
- 解除死锁的主要方法：
- 资源剥夺法：
- 挂起（暂时放到外存上）某些死锁进程，并抢占它的资源，将这些资源分配给其他的死锁进程。但是应防止被挂起的进程长时间得不到资源而饥饿
- 撤销进程法/终止进程法：
- 强制撤销部分、甚至全部死锁进程，并剥夺这些进程的资源。这种方式的优点是实现简单，但所付出的代价可能会很大。因为有些进程可能已经运行了很长时间，已经接近结束了，一旦被终止可谓功亏一篑，以后还得从头再来
- 进程回退法：
- 让一个或多个死锁进程回退到足以避免死锁的地步。这就要求系统要记录进程的历史信息，设置还原点
- 资源剥夺法：
优先对哪些进程进行死锁解除可参照以下因素：
- 进程优先级
- 已执行多长时间
- 还要多久能完成
- 进程已经使用了多少资源
- 进程是交互式的还是批处理式的
本文来自博客园，作者：GK_Jerry，转载请注明原文链接：https://www.cnblogs.com/GKJerry/articles/18379910
浙公网安备 33010602011771号