本篇笔记课程来源:王道计算机考研 操作系统
【操作系统】第二章:进程管理(下)
十二、进程同步和互斥
1. 进程同步
- 进程具有异步性的特征。各并发执行的进程以各自独立的、不可预知的速度向前推进。
- 同步又称直接制约关系,指为完成某种任务而建立的两个或多个进程,这些进程因为需要在某些位置上协调它们的工作次序而产生的制约关系。进程间的直接制约关系就是源于它们之间的相互合作。
2. 进程互斥
- 临界资源:一个时间段内只允许一个进程使用的资源(比如摄像头、打印机)。对临界资源的访问,必须互斥地进行。
- 进程互斥:指当一个进程访问某临界资源时,另一个想要访问该临界资源的进程必须等待。当前访问临界资源的进程访问结束,释放该资源后,另一个进程才能去访问临界资源。
- 对临界资源的互斥访问,逻辑上分为四个部分:
- 进入区:负责检查是否可进入临界区,若可进入,则应设置 正在访问临界资源的标志(上锁),以防止其他进程同时进入临界区
- 临界区:也称为临界段,负责访问临界资源
- 退出区:负责解除 正在访问临界资源的标志(解锁)
- 剩余区:做其他处理
- 为了实现对临界资源的互斥访问,同时保证系统整体性能,需要遵循以下原则:
- 空闲让进:临界区空闲时,可以允许一个请求进入临界区的进程立即进入临界区。
- 忙则等待:当已有进程进入临界区时,其他试图进入临界区的进程必须等待。
- 有限等待:对请求访问的进程,应保证能在有限时间内进入临界区(保证不会饥饿)。
- 让权等待:当进程不能进入临界区时,应立即释放处理机,防止进程忙等待。
十三、进程互斥的软件实现方法
1. 单标志法
- 算法思想:两个进程在访问完临界区后会把使用临界区的权限转交给另一个进程。也就是说每个进程进入临界区的权限只能被另一个进程赋予。
int turn = 0;
// P0进程 // P1进程
while (turn != 0); while (turn != 0); // 进入区
critical section; critical section; // 临界区
turn = 1; turn = 0; // 退出区
remainder section; remainder section; // 剩余区
- 该算法可以实现 “同一时刻最多只允许一个进程访问临界区”
- 但是违背 “空闲让进” 原则
2. 双标志先检查
- 算法思想:设置一个布尔值数组
flag[],数组中各个元素用来标记各进程想进入临界区的意愿(比如flag[0]=true意味着0号进程P0现在想进入临界区) - 每个进程在进入临界区之前先检查当前有没有别的进程想进入临界区,如果没有,则把自身对于的标志
flag[i]设为true,之后开始访问临界区。
bool flag[2]; // 表示进入临界区意愿的数组
flag[0] = false;
flag[1] = false; // 刚开始设置为两个进程都不想进入临界区
// P0进程 // P1进程
while (flag[1]); while (flag[0]); // 进入区 —— 检查
flag[0] = true; flag[1] = true; // 进入区 —— 上锁
critical section; critical section; // 临界区
flag[0] = false; flag[1] = false; // 退出区
remainder section; remainder section; // 剩余区
- 该算法在进入区的检查和上锁两个处理不是一气呵成的。检查后,上锁前可能发生进程切换。因此,违反 “忙则等待” 原则。
3. 双标志后检查
- 算法思想:是双标志先检查的改版。
- 双标志先检查是 先检查后上锁
- 双标志后检查是 先上锁后检查
bool flag[2]; // 表示进入临界区意愿的数组
flag[0] = false;
flag[1] = false; // 刚开始设置为两个进程都不想进入临界区
// P0进程 // P1进程
flag[0] = true; flag[1] = true; // 进入区 —— 上锁
while (flag[1]); while (flag[0]); // 进入区 —— 检查
critical section; critical section; // 临界区
flag[0] = false; flag[1] = false; // 退出区
remainder section; remainder section; // 剩余区
- 该算法虽然解决了 “忙则等待” 的问题,但是违背了 “空闲让进” 和 “有限等待” 原则,会因各进程都长期无法访问临界资源而产生 “饥饿” 现象。
4. Peterson算法
- 算法思想:结合双标志法、单标志法的思想。如果双方都争着想进入临界区,那可以让进程尝试“孔融让梨”(谦让)。
bool flag[2]; // 表示进入临界区意愿的数组,初始值都是false
int turn = 0; // turn 表示优先让哪个进程进入临界区
// P0进程 // P1进程
flag[0] = true; flag[1] = true; // 进入区 —— 主动争取
turn = 1; turn = 0; // 进入区 —— 主动谦让
while (flag[1] && turn == 1); while (flag[0] && turn == 0); // 进入区 —— 检查
critical section; critical section; // 临界区
flag[0] = false; flag[1] = false; // 退出区
remainder section; remainder section; // 剩余区
- Peterson 算法遵循了空闲让进、忙则等待、有限等待三个原则,但是依然违背了让权等待的原则。
十四、进程互斥的硬件实现方法
1. 中断屏蔽方法
- 利用 “开/ 关中断指令” 实现。与原语实现思想相同。
- 优点:简单、高效。
- 缺点:不适用于多处理机;只适用于操作系统内核进程,不适用于用户进程。
2. TestAndSet(TS指令 / TSL指令)
- TestAndSet 指令,也可称为 TestAndSetLock 指令,简称 TS 指令或 TSL 指令。
- TSL 指令是用硬件实现的,执行的过程不允许被中断,只能一气呵成。
- 优点:实现简单,无需严格检查是否会有逻辑漏洞;适用于多处理机环境;
- 缺点:不满足让权等待原则。
3. Swap指令(XCHG指令)
- Swap 指令,也称为 Exchange 指令,简称 XCHG 指令。
- Swap 指令是用硬件实现的,执行的过程不允许被中断,只能一气呵成。
- 优点和缺点同 TSL 指令。
4. 互斥锁
- 互斥锁(mutex lock);需要连续循环忙等的互斥锁,都可称为自旋锁(spin lock)。
- 每个互斥锁有一个布尔变量 available,表示锁是否可用。
- 函数 acquire 获得锁,release 释放锁。都必须是原子操作,所以互斥锁通常采用硬件机制实现。
acquire(){
while (!available); // 忙等待
available = false; // 获得锁
}
release(){
available = true; // 释放锁
}
- 优点:等待期间不用切换进程上下文,多处理机系统中,若上锁时间短,则等待代价很低;因此常用于多处理机系统。
- 缺点:违反让权等待,不适用于单处理机系统。
十五、信号量机制
1. 信号量
- 信号量:是一个变量(可以是一个整数,也可以是更复杂的记录型变量),可以用一个信号量来表示系统中某种资源的数量。(比如:系统中只有一台打印机,就可以设置一个初值为1的信号量)
- 用户进程可以通过使用操作系统提供的一对原语来对信号量进行操作,从而实现进程互斥、进程同步。
- 一对原语:wait(S) 原语和 signal(S) 原语,函数调用时传入参数信号量S;
- wait、signal 原语常简称为 P、V 操作(荷兰语 proberen 和 verhogen)。因此也可以写为 P(S)、V(S)
2. 整型信号量
- 整形信号量:用一个整数型的变量作为信号量,用来表示系统中某种资源的数量。
int S = 1; // 初始化整形信号量S,表示当前系统中可用的资源数
void wait(int S) { // wait 原语,相当于 进入区
while (S <= 0); // 如果资源数不够,就一直循环等待
S = S - 1; // 如果资源数够,则占用一个资源
}
void signal(int S) { // signal 原语,相当于 退出区
S = S + 1; // 使用完资源后,在退出区释放资源
}
// P0进程 // P1进程
... ...
wait(S); wait(S); // 进入区,申请资源
使用资源... 使用资源... // 临界区,访问资源
signal(S); signal(S); // 退出区,释放资源
... ...
- 存在的问题:不满足让权等待原则。
3. 记录型信号量‼️ ⚠️
- 记录型信号量:用记录型数据结构表示的信号量。
typedef struct {
int value; // 剩余资源数
struct process *L; // 等待队列
} semaphore;
void wait(semaphore S) {
S.value--;
if (S.value < 0) {
// 如果剩余资源数不够,使用 block 原语使进程从运行态进入阻塞态
// 并把进程挂到信号量 S 的等待(阻塞)队列中
block(S.L);
}
}
void signal(semaphore S) {
s.value++;
if (S.value <= 0) {
// 释放资源后,若还有别的进程在等待这种资源,则使用 wakeup 原语
// 唤醒等待队列中的一个进程,该进程从阻塞态变为就绪态
wakeup(S.L);
}
}
- 该机制遵循了让权等待原则。
- 对信号量 S 的一次 P 操作意味着进程请求一个单位的该类资源,当该类资源已分配完毕,进程应调用 block 原语进行自我阻塞。
- 对信号量 S 的一次 V 操作意味着进程释放一个单位的该类资源,若释放后依然有进程在等待该类资源,应调用 wakeup 原语唤醒等待队列中的第一个进程。
4. 信号量机制实现进程互斥
- 步骤
- 分析并发进程的关键活动,划定临界区(如:对临界资源打印机的访问就应放在临界区)
- 设置互斥信号了 mutex,初值为 1
- 在进入区 P(mutex) —— 申请资源
- 在退出区 V(mutex) —— 释放资源
- 注意:
- 在不同的临界资源需要设置不同的互斥信号量;
- P、V 操作必须成对出现。
semaphore mutex = 1; // 初始化信号量
P1() {
...
P(mutex); // 使用临界资源前需要加锁
临界区代码段...
V(mutex); // 使用临界资源后需要解锁
...
}
5. 信号量机制实现进程同步
- 进程同步:要让各并发进程按要求有序地推进。
- 步骤:
- 分析什么地方需要实现 “同步关系”,即必须保证 “一前一后” 执行的两个操作
- 设置同步信号量 S,初始为 0
- 在 “前操作” 之后执行 V(S) —— 前 V
- 在 “后操作” 之前执行 P(S) —— 后 P
- 信号量 S 代表 “某种资源”,刚开始是没有这种资源的。P2 需要使用这种资源,只能由 P1 产生这种资源。
semaphore S = 0; // 初始化同步信号量,初始值为 0
P1() {
...
V(S);
...
}
P2() {
...
P(S);
...
}
6. 信号量机制实现进程的前驱关系
- 步骤:
- 要为每一对前驱关系各设置一个同步信号量
- 在 “前操作” 之后对相应的同步信号量执行 V 操作
- 在 “后操作” 之前对相应的同步信号量执行 P 操作
- 本质上是多级同步问题。
十六、进程同步 / 互斥问题
1. PV操作题目解题思路
- 关系分析。找出题目中描述的各个进程,分析它们之间的同步、互斥关系。
- 整理思路。根据各进程的操作流程确定 P、V 操作的大致顺序。
- 设置信号量。设置需要的信号量,并根据题目条件确定信号量初值。(互斥信号量初值一般为 1,同步信号量的初值要看对应资源的初值是多少)
2. 生产者消费者问题
- 问题描述:
- 系统中有一组生产者进程和一组消费者进程,生产者进程每次生产一个产品放入缓冲区,消费者进程每次从缓冲区取出一个产品并使用。
- 生产者、消费者共享一个初始为空、大小为 n 的缓冲区。
- 只有缓冲区没满时,生产者才能把产品放入缓冲区,否则必须等待。
- 只有缓冲区不空时,消费者才能从缓冲区取出产品,否则必须等待。
- 缓冲区是临界资源,各进程必须互斥地访问。
- 解决问题:
semaphore mutex = 1; // 互斥信号量,实现对缓冲区的互斥访问 semaphore empty = n; // 同步信号量,表示空闲缓冲区的数量 semaphore full = 0; // 同步信号量,表示产品的数量,也即非空缓冲区的数量 produce() { while (1) { 生产一个产品; P(empty); // 消耗一个空闲缓冲区 P(mutex); // 互斥 上锁 把产品放入缓冲区; V(mutex); // 互斥 解锁 V(full); // 增加一个产品 } } consumer() { while (1) { P(full); // 消耗一个产品(非空缓冲区) P(mutex); 从缓冲区取出一个产品; V(mutex); V(empty); // 增加一个空闲缓冲区 使用产品; } } - 实现互斥是在同一进程中进行一对 PV 操作
- 实现同步是在两个进程中分别进行 PV 操作
- 注意:
- 实现互斥的 P 操作一定要在实现同步的 P 操作之后 ,否则会发生死锁。
- V 操作不会导致进程阻塞,因此两个 V 操作顺序可以互换。
3. 多生产者-多消费者问题
- 问题描述:
- 桌子上有一个盘子,每次只能向其中放入一个水果。
- 爸爸专向盘子中放苹果,妈妈专向盘子中放橘子;儿子专等着吃盘子中的橘子,女儿专等着吃盘子中的苹果。
- 只有盘子空时,爸爸或妈妈才可向盘子中放一个水果。仅当盘子中有自己需要的水果时,儿子或女儿可以从盘子中取出水果。
- 解决问题:
semaphore mutex = 1; // 实现互斥访问 semaphore apple = 0; // 盘子中有多少个苹果 semaphore orange = 0; // 盘子中有多少个橘子 semaphore plate = 1; // 盘子中还可以放多少个水果 dad() { while (1) { 准备一个苹果; P(plate); P(mutex); 把苹果放入盘子; V(mutex); V(apple); } } mom() { while (1) { 准备一个橘子; P(plate); P(mutex); 把橘子放入盘子; V(mutex); V(orange); } } daughter() { while (1) { P(apple); P(mutex); 从盘中取走苹果; V(mutex); V(plate); 吃掉苹果; } } son() { while (1) { P(orange); P(mutex); 从盘中取走橘子; V(mutex); V(plate); 吃掉橘子; } } - 在该问题中,如果缓冲区大小为 1,那么有可能不需要设置互斥信号量就可以实现互斥访问缓冲区的功能。
4. 吸烟者问题
- 问题描述:
- 假设一个系统有三个抽烟者进程和一个供应者进程。每个抽烟者不停地卷烟并抽掉它,但是要卷起并抽掉一支烟,抽烟者需要有三种材料:烟草、纸和胶水。
- 三个抽烟者中,第一个拥有烟草、第二个拥有纸、第三个拥有胶水。
- 供应者进程无限地提供三种材料,供应者每次将两种材料放桌子上,拥有剩下那种材料的抽烟者卷一根烟并抽掉它,并给供应者进程一个信号告诉完成了,供应者就会放另外两种材料在桌上
- 这个过程一直重复,让三个抽烟者进程轮流地抽烟。
- 解决问题:
semaphore offer1 = 0; // 桌上组合一的数量 semaphore offer2 = 0; // 桌上组合二的数量 semaphore offer3 = 0; // 桌上组合三的数量 semaphore finish = 0; // 抽烟是否完成 int i = 0; // 用于实现三个抽烟者轮流抽烟 provider() { while (1) { if (i == 0) { 将组合一放桌上; V(offer1); } else if (i == 1) { 将组合二放桌上; V(offer2); } else if (i == 2) { 将组合三放桌上; V(offer3); } i = (i + 1) % 3; P(finish); } } smoker1() { while (1) { P(offer1); 从桌上拿走组合一;卷烟;抽掉; V(finish); } } smoker2() { while (1) { P(offer2); 从桌上拿走组合二;卷烟;抽掉; V(finish); } } smoker3() { while (1) { P(offer3); 从桌上拿走组合三;卷烟;抽掉; V(finish); } }
5. 读者写者问题
- 问题描述:
- 有读者和写者两组并发进程,共享一个文件,当两个或两个以上的读进程同时访问共享数据时不会产生副作用,但若某个写进程和其他进程(读进程或写进程)同时访问共享数据时则可能导致数据不一致的错误。
- 允许多个读者可以同时对文件执行读操作
- 只允许一个写者往文件中写信息
- 任一写者在完成写操作之前不允许其他读者或写者工作
- 写者执行写操作前,应让已有的读者和写者全部退出
- 解决问题
semaphore rw = 1; // 用于实现对共享文件的互斥访问 int count = 0; // 记录当前有几个读进程在访问文件 semaphore mutex = 1; // 用于保证对 count 变量的互斥访问 semaphore w = 1; // 用于实现读写公平 writer() { while (1) { P(w); // 防止源源不断的读进程 P(rw); // 写之前 “加锁” 写文件; V(rw); // 写完了 “解锁” V(w); } } reader() { while (1) { P(w); // 如果正在读,则不允许再有写进程 P(mutex); // 各读进程互斥访问 count,对 count 变量的检查和赋值一气呵成 if (count == 0) { // 由第一个读进程负责 P(rw); // 读之前 “加锁” } count++; // 访问文件的读进程数 + 1 V(mutex); V(w); 读文件; P(mutex); count--; // 访问文件的读进程数 - 1 if (count == 0) { // 由最后一个读进程负责 V(rw); // 读完了 “解锁” } V(mutex); } } - 在这种算法中,采用了相对公平的 FCFS 原则,也可以称为 “读写公平法”。
- 核心思想在于设置了一个计数器 count 用来记录当前访问共享文件的读进程数。可以用 count 的值来判断当前进入的进程是否是第一个 (加锁) / 最后一个 (解锁) 读进程,从而做出不同的处理。
6. 哲学家进餐问题
- 问题描述:
- 一张圆桌上坐着 5 名哲学家,每两个哲学家之间的桌上摆一根筷子,桌子的中间是一碗米饭。哲学家们倾注毕生的精力用于思考和进餐,哲学家们思考,并不影响他人。
- 只有当哲学家饥饿时,才试图拿起左、右两根筷子(一根一根地拿起)。
- 如果筷子已在他人手上,则需等待。
- 饥饿的哲学家只有同时拿起两根筷子才可以开始进餐,当进餐完毕后,放下筷子继续思考。
- 解决方法:
- 最多允许四个哲学家同时进餐,这样可以保证至少有一个哲学家是可以拿到左右两只筷子的
- 要求奇数号哲学家先拿左边的筷子,然后再拿右边的筷子;偶数号哲学家刚好相反。
- 仅当一个哲学家左右两只筷子都可用时才允许他抓起筷子。
十七、管程
1. 管程的引入
- 管程是一种高级同步机制,在程序设计语言 Pascal 中首次引入。
- 为解决信号量机制存在的编写程序困难、易出错问题,管程机制让程序呀在写程序时不需要再关注复杂的 PV 操作。
2. 管程的定义
- 管程是一种特殊的软件模块,由以下部分组成:
- 局部于管程的共享数据结构说明;
- 对该数据结构进行操作的一组过程;
- 对局部于管程的共享数据设置初始值的语句;
- 管程有一个名字。
- 管程类似于类;过程类似于函数或方法。
3. 管程的基本特征
- 局部于管程的数据只能被局部于管程的过程所访问;
- 需要在管程中定义共享数据
- 一个进程只有通过调用管程内的过程才能进入管程访问共享数据;
- 需要在管程中定义用于访问共享数据的 “入口” —— 过程(函数)
- 只有通过这些特定的入口才能访问共享数据
- 管程的互斥特性是由编译器负责实现的
- 每次仅允许一个进程在管程内执行某个内部过程
- 管程有很多入口,但每次只能开放其中一个入口,并且只能让一个进程或线程进入
- 可以管程中设置条件变量和等待 / 唤醒操作,以解决同步问题。
4. 管程解决生产者消费者问题
伪代码:
monitor 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;
}
}
十八、死锁
1. 死锁的概念
- 什么是死锁?
- 在并发环境下,各进程因竞争资源而造成的一种 互相等待对方手里的资源,导致各进程都阻塞,都无法向前推进 的现象,就是 “死锁”。
- 发生死锁后,若无外力干涉,这些进程都将无法向前推进。
- 死锁、饥饿、死循环的区别
- 死锁:各进程互相等待对方手里的资源,导致各进程都阻塞,无法向前推进的现象。至少有两个或两个以上的进程同时发生死锁。
- 饥饿:由于长期得不到想要的资源,某进程无法向前推进的现象。可能只有一个进程发生饥饿。
- 死循环:某进程执行过程中一直跳不出某个循环的现象。可能只有一个进程发生死循环。死锁和饥饿时管理者(操作系统)的问题,死循环是被管理者的问题。
- 产生死锁必须同时满足以下四个条件,只要其中任一条件不成立,死锁就不会发生:
- 互斥条件:只有对必须互斥使用的资源的争抢才会导致死锁。
- 不剥夺条件:进程所获得的资源在未使用完之前,不能由其他进程强行夺走,只能主动释放。
- 请求和保持条件:进程已经保持了至少一个资源,但又提出了新的资源请求,而该资源又被其他进程占有,此时请求进程被阻塞,但又对自己已有的资源保持不放。
- 循环等待条件:存在一种进程资源的循环等待链,链中的每一个进程已获得的资源同时被下一个进程所请求。
- 注意:发生死锁时一定有循环等待,但是发生循环等待时未必死锁(循环等待是死锁的必要不充分条件)
- 什么时候会发生死锁:
- 对系统资源的竞争。各进程对不可剥夺的资源的竞争可能引起死锁,对可剥夺的资源的竞争是不会引起死锁的。
- 进程推进顺序非法。
- 循环等待条件信号量的使用不当也会造成死锁。
- 总是:对不可剥夺资源的不合理分配,可能导致死锁。
- 死锁的处理策略:
- 预防死锁:破坏死锁产生的四个必要条件中的一个或几个。
- 避免死锁:用某种方法防止系统进入不安全状态,从而避免死锁(银行家算法)。
- 死锁的检测和解除:允许死锁的发生,不过操作系统会负责检测出死锁的发生,然后采取某种措施解除死锁。
2. 死锁的处理策略 —— 预防死锁
- 破坏互斥条件:
- 互斥条件:只有对必须互斥使用的资源的争抢才会导致死锁。
- 破坏:如果把只能互斥使用的资源改造成允许共享使用,则系统不会进入死锁状态。(比如:SPOOLing 技术。操作系统可以采用 SPOOLing 技术吧独占设备在逻辑上改造成共享设备)
- 缺点: 并不是所有的资源都可以改造成可共享使用的资源。并且为了系统安全,很多地方还必须保护这种互斥性。因此,很多时候无法破坏互斥条件。
- 破坏不剥夺条件:
- 不剥夺条件:进程所获得的资源在未使用完之前,不能由其他进程强行夺走,只能主动释放。
- 破坏:
- 方案一:当某个进程请求新的资源得不到满足时,它必须立即释放保持的所有资源,待以后需要时再重新申请。
- 方案二:当某个进程需要的资源被其他进程所占有的时候,可以由操作系统协助,将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级。
- 缺点:
- 实现起来比较复杂
- 释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源,如 CPU。
- 反复地申请和释放资源会增加系统开销,降低系统吞吐量。
- 若采用方案一,意味着只要暂时得不到某个资源,之前获得的那些资源都需要放弃,以后再重新申请。如果一直发生这样的情况,就会导致进程饥饿。
- 破坏请求和保持条件:
- 请求和保持条件:进程已经保持了至少一个资源,但又提出了新的资源请求,而该资源又被其他进程占有,此时请求进程被阻塞,但又对自己已有的资源保持不放。
- 破坏:采用静态分配方法。即进程在运行前一次申请完它所需要的全部资源,在它的资源为满足之前,不让它投入运行。一旦投入运行后,这些资源就一直归它所有,该进程就不会再请求别的任何资源。
- 缺点:有些进程可能只需要用很短的时间,因此如果进程的整个运行期间都一直保持着所有资源,就会造成严重的资源浪费,资源利用率极低。且该策略也有可能导致某些进程饥饿。
- 破坏循环等待条件:
- 循环等待条件:存在一种进程资源的循环等待链,链中的每一个进程已获得的资源同时被下一个进程所请求。
- 破坏:采用顺序资源分配法。首先给系统中的资源编号,规定每个进程必须按编号递增的顺序请求资源,同类资源(即编号相同的资源)一次申请完。
- 原理:一个进程只有已占有小编号的资源时,才有资格申请更大编号的资源。按此规则,已持有大编号资源的进程不可能逆向地回来申请小编号的资源,从而就不会产生循环等待的现象。
- 缺点:
- 不方便增加新的设备,因为可能需要重新分配所有的编号
- 进程实际使用的资源的顺序可能和编号递增顺序不一致,会导致资源浪费
- 必须按规定次序申请资源,用户编程麻烦
3. 死锁的处理策略 —— 避免死锁
- 安全序列:指如果系统按照这种序列分配资源,则每个进程都能顺利完成。
- 安全序列、不安全状态、死锁的联系:
- 只要能找出一个安全序列,系统就是安全状态。安全序列可能有多个。
- 如果分配了资源之后,系统中找不出任何一个安全序列,系统就进入了不安全状态。这就意味着之后可鞥所有进程都无法顺利的执行下去。
- 如果有进程提前归还了一些资源,那系统也有可能重新回到安全状态,不过在分配资源之前总要考虑到最坏的情况。
- 如果系统处于安全状态,就一定不会发生死锁。如果系统进入不安全状态,就可能发生死锁。(处于不安全状态未必就是发生了死锁,但发生死锁时一定是在不安全状态)
- 因此可以在资源分配之前预先判断这次分配是否会导致系统进入不安全状态,以此决定是否答应资源分配请求。这也是 “银行家算法” 的核心思想。
- 银行家算法:在进程提出资源请求时,先预判此次分配是否会导致系统进入不安全状态。如果会进入不安全状态,就暂时不答应这次请求,让该进程先阻塞等待。
- 银行家算法数据结构:
- 长度为 m 的一位数组 Available 表示还有多少可用资源
- n * m 矩阵 Max 表示各进程对资源的最大需求数
- n * m 矩阵 Allocation 表示已经给各进程分配了多少资源
- Max - Allocation = Need 矩阵表示各进程最多还需要多少资源
- 用长度为 m 的一位数组 Request 表示进程此次申请的各种资源数
- 银行家算法步骤:
- 检查此次申请是否超过了之前声明的最大需求数;否则认为出错
R e q u e s t i [ j ] ≤ N e e d [ i , j ] ( 0 ≤ j ≤ m ) Request_i[j] \leq Need[i,j](0 \leq j \leq m) Requesti[j]≤Need[i,j](0≤j≤m) - 检查此时系统剩余的可用资源是否还能满足这次请求;否则尚无足够资源,进程
P
i
P_i
Pi 必须等待
R e q u e s t i [ j ] ≤ A v a i l a b l e [ j ] ( 0 ≤ j ≤ m ) Request_i[j] \leq Available[j](0 \leq j \leq m) Requesti[j]≤Available[j](0≤j≤m) - 试探着分配,更改各数据结构
A v a i l a b l e = A v a i l a b l e − R e q u e s t ; A l l o c a t i o n [ i , j ] = A l l o c a t i o n [ i , j ] − R e q u e s t i [ j ] ; N e e d [ i , j ] = N e e d [ i , j ] − R e q u e s t i ] j ] ; \begin{align} &Available=Available-Request; \\ &Allocation[i,j]=Allocation[i,j]-Request_i[j];\\ &Need[i,j]=Need[i,j]-Request_i]j]; \end{align} Available=Available−Request;Allocation[i,j]=Allocation[i,j]−Requesti[j];Need[i,j]=Need[i,j]−Requesti]j]; - 用安全性算法检查此次分配是否会导致系统进入不安全状态
- 检查此次申请是否超过了之前声明的最大需求数;否则认为出错
- 安全性算法步骤:
- 检查当前的剩余可用资源是否能满足某个进程的最大需求,如果可以,就把该进程加入安全序列,并把该进程持有的资源全部回收。
- 不断重复步骤一,看最终是否能让所有进程都加入安全序列。
4. 死锁的处理策略 —— 检测和解除
- 死锁检测算法数据结构,保存资源的请求和分配信息(资源分配图):
- 两种结点:
- 进程结点:对应一个进程
- 资源结点:对应一类资源,一类资源可能有多个
- 两种边:
- 请求边(进程结点 → 资源结点):表示进程想申请几个资源(每条边代表一个)
- 分配边(资源结点 → 进程结点):表示已经为进程分配了几个资源(每条边代表一个)

- 两种结点:
- 死锁检测算法(依次消除与不阻塞进程相连的边,直到无边可消):
- 在资源分配图中,找出既不阻塞又不是孤点的进程 P i P_i Pi (即一条有向边与它相连,且该有向边对应资源的申请数量小于等于系统中已有空闲资源数量),消去它所有的请求边和分配边,使之成为孤立的结点。
- 进程 P i P_i Pi 所释放的资源,可以唤醒某些因等待这些资源而阻塞的进程,原来的阻塞进程可能变为非阻塞进程。
- 若能消去图中所有边,则称该图是可完全简化的,此时一定没有发生死锁。如果某时刻系统的资源分配图是不可完全简化的,那么此时系统死锁。
- 并不是系统中所有的进程都是死锁状态,用死锁检测算法化简资源分配图后,还连着边的进程就是死锁进程。
- 解除死锁的方法:
- 资源剥夺法:挂起(暂时放到外存上)某些死锁进程,并抢占它的资源,将这些资源分配给其他的死锁进程。但是应防止被挂起的进程长时间得不到资源而饥饿。
- 撤销进程法(终止进程法):强制撤销部分、甚至全部死锁进程,并剥夺这些进程的资源。这种方式的优点是实现简单,但所付出的代价可能会很大。
- 进程回退法:让一个或多个死锁进程回退到足以避免死锁的地步。这就要求系统要记录进程的历史信息,设置还原点。
- 从以下方面考虑处理哪个死锁进程:
- 进程优先级(先终止低优先级的)
- 已执行时间(先终止时间短的)
- 还要多久完成(先终止还要很长时间才能完成的进程)
- 进程已经使用了多少资源(先终止资源更多的进程)
- 交互式还是批处理(先终止批处理进程)



&spm=1001.2101.3001.5002&articleId=143575061&d=1&t=3&u=789eb1753e9544e19b2ed2462650e14b)
7503

被折叠的 条评论
为什么被折叠?



