操作系统11----死锁

                                                             死锁

1.死锁问题

1.1资源分配图

1.2出现死锁的必要条件

2.死锁处理方法

2.1死锁预防：限制申请方式

2.2死锁避免

3.银行家算法（Banker's Algorithm）

3.1数据结构

3.2安全状态判断

3.3银行家算法

4.死锁检测

4.1死锁检测算法：数据结构

4.2死锁检测算法

4.3死锁恢复: 

---

1.死锁问题

由于竞争资源或者通信关系，两个或更多线程在执行中出现，永远相互等待只能由其他进程引发的事件

资源分类

可重用资源（Reusable Resource）资源不能被删除且在任何时刻只能有一个进程使用，进程释放资源后，其他进程可重用

消耗资源(Consumable resource) 资源创建和销毁

1.1资源分配图

描述资源和进程间的分配和占用关系的有向图

两类顶点：

系统中的所有进程 P = {P1, P2, …, Pn}

系统中的所有资源 R = {R1, R2, …, Pm}

两类有向边：

资源请求边 进程Pi请求资源Rj：Pi -->Rj

资源分配边 资源Rj已分配给进程Pi：Rj-->Pi

1.2出现死锁的必要条件

1.互斥 任何时刻只能有一个进程使用一个资源实例;

2.持有并等待 进程保持至少一个资源，并正在等待获取其他进程持有的资源;

3.非抢占 资源只能在进程使用后自愿释放;

4.循环等待  存在等待进程集合{P0，P1，...，PN} ，P0正在等待P1所占用的资源，P1 正在等待P2占用的资源，...，PN-1在等待PN所占用资源，PN正在等待P0所占用的资源;

   

左边会出现死锁，右边不会出现死锁，P2,P4会在一定时间内释放资源R1,R2，因此系统会继续执行下去。

---

2.死锁处理方法

死锁预防(Deadlock Prevention)  确保系统永远不会进入死锁状态

死锁避免(Deadlock Avoidance) 在使用前进行判断，只允许不会出现死锁的进程请求资源

死锁检测和恢复(Deadlock Detection & Recovery) 在检测到运行系统进入死锁状态后，进行恢复

由应用进程处理死锁 通常操作系统忽略死锁，大多数操作系统（包括UNIX）的做法

2.1死锁预防：限制申请方式

预防是采用某种策略，限制并发进程对资源的请求，使系统在任何时刻都不满足死锁的必要条件。

互斥 把互斥的共享资源封装成可同时访问；

持有并等待 进程请求资源时，要求它不持有任何其他资源；仅允许进程在开始执行时，一次请求所有需要的资源；资源利用率低；

非抢占 如进程请求不能立即分配的资源，则释放已占有资源；只在能够同时获得所有需要资源时，才执行分配操作；

循环等待 对资源排序，要求进程按顺序请求资源；

2.2死锁避免

利用额外的先验信息，在分配资源时判断是否会出现死锁，只在不会死锁时分配资源。

要求进程声明需要资源的最大数目；

限定提供与分配的资源数量，确保满足进程的最大需求；

动态检查的资源分配状态，确保不会出现环形等待；

系统资源分配的安全状态

当进程请求资源时，系统判断分配后是否处于安全状态。

系统处于安全状态 针对所有已占用进程，存在安全序列。

序列<P1，P2，...，PN>是安全的

Pi要求的资源≤当前可用资源+所有Pj 持有资源，其中j<i

如Pi的资源请求不能立即分配，则Pi等待所有Pj（j<i）完成

Pi完成后，Pi +1可得到所需资源，执行并释放所分配的资源

最终整个序列的所有Pi都能获得所需资源

安全状态与死锁的关系

系统处于安全状态，一定没有死锁；系统处于不安全状态，可能出现死锁；避免死锁就是确保系统不会进入不安全状态；

---

3.银行家算法（Banker's Algorithm）

银行家算法是一个避免死锁产生的算法。以银行借贷分配策略为基础，判断并保证系统处于安全状态。

3.1数据结构

n = 线程数量, m = 资源类型数量

Max（总需求量）: n×m矩阵  线程Ti最多请求类型Rj的资源 Max[i,j] 个实例

Available（剩余空闲量）：长度为m的向量 当前有 Available[j] 个类型Rj的资源实例可用

Allocation（已分配量）：n×m矩阵 线程Ti 当前分配了 Allocation[i, j] 个Rj的实例

Need（未来需要量）：n×m矩阵 线程Ti 未来需要 Need[i, j] 个Rj资源实例

四个矩阵，列表示各种资源量  Max线程总需求量  Available剩余空闲量  Allocation已分配量  Need未来需要量

Need[i,j] = Max[i,j] – Allocation[i,j]

3.2安全状态判断

1.Work 和Finish 分别是长度为m和n的向量初始化:

   Work = Available     //当前资源剩余空闲量

   Finish[i] = false for i：1,2, …, n.      //线程i没结束

2.寻找线程Ti:

   (a) Finish[i] = false  

   (b) Need[i]≤Work   //接下来找出Need比Work小的线程i

没有找到满足条件的Ti，转4。

3.Work = Work + Allocation[i]     //线程i的资源需求量小于当前剩余空闲资源量, 所以配置给它再回收
   Finish[i] = true
   转2.

4.如所有线程Ti满足Finish[i] == true，则系统处于安全状态。

Work为资源剩余量，Finish表示每个线程是否完成，寻找如果某个线程需求资源小于Work，则说明该线程可以运行结束，结束之后，记录线程结束状态，将该线程占用的资源释放回Work；继续寻找下一个线程。。如果最终所有线程都处于完成状态，则说明处于安全状态；如果有线程没有完成，当不满足资源条件，则说明处于不安全状态。

3.3银行家算法

初始化: Requesti 线程Ti的资源请求向量  Requesti[j] 线程Ti请求资源Rj的实例

循环:

1.如果 Requesti ≤ Need[i], 转到步骤2。否则, 拒绝资源申请, 因为线程已经超过了其最大要求；

2.如果 Requesti ≤ Available, 转到步骤3。否则, Ti 必须等待, 因为资源不可用；

3.通过安全状态判断来确定是否分配资源给Ti : 生成一个需要判断状态是否安全的资源分配环境

           Available = Available -Requesti;

           Allocation[i]= Allocation[i] + Requesti;

           Need[i]= Need[i]–Requesti;

           调用安全状态判断   如果返回结果是安全，将资源分配给Ti；如果返回结果是不安全，系统会拒绝Ti的资源请求

初始化线程资源请求量，如果请求量大于需求量，则拒绝，说明此时线程请求资源超过最大允许请求量；

如果请求量大于剩余量，说明当前资源不足，则线程等待；否则，假定将请求资源分配给线程，计算剩余量，分配量以及未来需求量；调用安全状态判断，如果分配给线程给资源，使得系统处于不安全状态，则不进行分配。

银行家算法的安全状态判断示例

初始状态 

可知此时T2资源请求量小于剩余量，因此可以执行T2，T2执行完毕，则需要释放已分配资源，将T2已分配资源6，1，2加入到剩余量中得到6，2，3

由上状态可知，下一步可以执行T1,T1执行完毕，释放T1已分配资源1,0,0加入到剩余量得到7,2,3

T3执行，释放T3已分配资源  2,1,1加入到7,2,3中得到9,3,4

---

4.死锁检测

允许系统进入死锁状态，维护系统的资源分配图，定期调用死锁检测算法来搜索图中是否存在死锁，出现死锁时，用死锁恢复机制进行恢复。

4.1死锁检测算法：数据结构

Available: 长度为m的向量，每种类型可用资源的数量

Allocation: 一个n×m矩阵，当前分配给各个进程每种类型资源的数量，进程Pi 拥有资源Rj的Allocation[i, j]个实例

4.2死锁检测算法

1.Work 和Finish 分别是长度为m和n的向量初始化:

(a)Work = Available 

(b)Allocation[i]> 0 时, Finish[i] = false;   否则，Finish[i] = true

2.寻找线程Ti满足:

   (a)Finish[i] = false

   (b)Requesti≤Work

   没有找到这样的i，转到4

3.Work = Work + Allocation[i]
   Finish[i] = true
   转到2

4.如某个Finish[i] == false，系统处于死锁状态

死锁检测示例

下一步可以执行T0，T2  执行T0,T2之后

执行T1，T3，T4

4.3死锁恢复: 

进程终止

终止所有的死锁进程

一次只终止一个进程直到死锁消除

资源抢占

选择被抢占进程

进程回退 返回到一些安全状态, 重启进程到安全状态

可能出现饥饿 同一进程可能一直被选作被抢占者

参考：清华大学 操作系统  陈渝  http://os.cs.tsinghua.edu.cn/oscourse/OS2015/