操作系统考试复习——第三章 预防死锁 避免死锁

预防死锁：就是破坏死锁产生的四个条件之一就行。

0.破坏互斥条件：由于互斥条件是非共享设备所必须的所以，不仅不能改变还需要保证。因此我们主要考虑剩下的三个条件。

1.破坏"请求和保持"条件

请求和保持也就是系统已经请求了一个资源它现在占有这个资源但是它在没有释放的前提下还申请新的资源。

解决办法：

1)在所有进程开始之前就申请所有的资源，这样在整个运行期间就不会再申请了。这样的解决方式简单，但是由于需要一次性地分配大量资源会造成大量资源的浪费以及会产生部分进程无法得到相应的资源导致的部分进程饥饿现象。

2)允许一个进程只获得初期所需要的资源就可以开始运行，在运行过程中再逐步释放已经分配给自己的资源，且已经用毕的资源。这个就会比第一个解决方法更合理。

2.破坏"不可抢占"条件

当某个进程请求新的资源得不到满足时，它必须立即释放保持的所有资源，待以后需要时再重新申请。也就是说，进程已占有的资源会被短暂地释放，即使某些资源尚未使用完，也需要主动释放，从而破坏了不可抢占条件。

该解决方法的缺点：

1.实现起来比较复杂。
2.释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源，如CPU。
3.反复地申请和释放资源会增加系统开销，降低系统吞吐量。
4.只要暂时得不到某个资源，之前获得的那些资源就都需要放弃，以后再重新申请。如果一直发生这样的情况，就会导致进程饥饿。

3.破坏循环等待条件
可采用顺序资源分配法。首先给系统中的资源编号，规定每个进程必须按编号递增的顺序请求资源， 同类资源（即编号相同的资源）一次申请完。

一个进程只有已占有小编号的资源时，才有资格申请更大编号的资源。按此规则，已持有大编号资源的进程不可能逆向地回来申请小编号的资源，从而就不会产生循环等待的现象。

该策略的缺点：

1. 不方便增加新的设备，因为可能需要重新分配所有的编号；
2. 进程实际使用资源的顺序可能和编号递增顺序不一致，会导致资源浪费；
3. 必须按规定次序申请资源，用户编程麻烦。

避免死锁：

避免死锁也是属于事先预防的策略，但并不是事先采取某种限制措施，破坏产生死锁的必要条件，而是在资源动态分配的过程中，防止系统进入不安全状态，以避免发生死锁。

1.安全序列：所谓安全序列，就是指如果系统按照这种序列分配资源，则每个进程都能顺利完成。只要能找出一个安全序列，系统就是安全状态。当然，安全序列可能有多个。

如果分配了资源之后，系统中找不出任何一个安全序列，系统就进入了不安全状态。这就意味着之后可能所有进程都无法顺利的执行下去。当然，如果有进程提前归还了一些资源，那系统也有可能重新回到安全状态，不过我们在分配资源之前总是要考虑到最坏的情况。

如果系统处于安全状态，就一定不会发生死锁，如果系统进入不安全，就可能发生死锁（处于不安全状态未必就是发生了死锁，但发生死锁时一定是在不安全状态）
因此可以在资源分配之前预先判断这次分配是否会导致系统进入不安全状态，以此决定是否答应资源分配请求。这也是“银行家算法”的核心思想。
利用银行家算法来避免死锁详见：操作系统——银行家算法避免死锁问题_利用银行家算法避免死锁_用编程写诗的博客-CSDN博客

银行家算法的一个例题：

假定系统中有5个进程{P0,P1,P2,P3,P4}和三类资源{A,B,C}，各种资源的数量分别为10，5，7，在T0时刻的资源分配情况如图所示：

	Max	Allocaiton	Need	Available
	A  B  C	A  B   C	A   B   C	A  B  C
P0	7  5  3	0  1  0	7  4  3	3  3  2（2，3，0）
P1	3  2  2	2  0  0（3，0，2）	1  2  2（0，2，0）
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

在T0时刻的安全性：利用安全性算法对T0时刻的资源分配情况进行分析可知，在T0时刻存在一个安全序列{P1,P3,P4,P2,P0}，故系统是安全的。

	Work	Need	Allocation	Work+Allocation	Finish
	A  B  C	A  B   C	A   B   C	A  B  C
P1	3  3  2	1  2  2	2  0  0	5  3  2	true
P3	5  3  2	0  1  1	2  1  1	7  4  3	true
P4	7  4  3	4  3  1	0   0  2	7  4  5	true
P2	7  4  5	6  0  0	3  0  2	10  4  7	true
P0	10  4  7	7  4  3	0  1  0	10  5  7	true

下面用三种情况来展示银行家算法的三种情况，这里三种情况是一个连续执行的情景。所以下面情况中的数据是承接上面情况的。这里可能有疑惑，提示一下。

第一种情况：P1请求资源：P1发出请求向量Request(1,0,2),系统按银行家算法进行检查

Request(1,0,2)<=Need(1,2,2)   Request(1,0,2)<=Available(3,3,2)

系统给P1分配资源并对Available,Allocation和Need第一个表格中括号内容即为分配后的结果

再利用安全性算法进行验证也可以得到一个安全序列{P1,P3,P4,P0,P2}所以就分配

	Work	Need	Allocation	Work+Allocation	Finish
	A  B  C	A  B   C	A   B   C	A  B  C
P1	2  3  0	0  2  0	3  0  2	5  3  2	true
P3	5  3  2	0  1  1	2  1  1	7  4  3	true
P4	7  4  3	4  3  1	0   0  2	7  4  5	true
P0	7  4  5	7  4  3	0  1  0	7  5  5	true
P2	7  5  5	6  0  0	3  0  2	10  5  7	true

第二种情况：P4请求资源：P4发出请求向量Request(3,3,0)，系统按银行家算法进行检查

Request(3,3,0)<=Need(4,3,1)

Request(3,3,0)>Available(2,3,0)让P4等待

第三种情况：P0请求资源：P0发出请求向量Request(0,2,0),系统按银行家算法进行检查：

Request(0,2,0)<=Need(7,4,3)

Request(0,2,0)<=Available(2,3,0)

系统先假定给P0分配资源然后进行修改

	Max	Allocaiton	Need	Available
	A  B  C	A  B   C	A   B   C	A  B  C
P0	7  5  3	0  3  0	7  2  3	2   1  0
P1	3  2  2	3  0  2	0  2  0
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

进行安全性检查发现可用资源已经无法满足任何进程的需要了所以系统会处于不安全状态这样就不会分配资源