ch7 Deadlocks 死锁
作者:互联网
System Model
进程按如下顺序使用资源:
- request 如果申请不能立即被允许(例如,所申请资源正在为其他进程所使用),那么申请进程必须等待,直到它获得该资源为止。
- use 进程对资源进行操作
- release进程释放资源。
Deadlock 死锁:当一组进程中的每个进程都在等待一个事件,而这一事件只能由这一组进程的另一进程引起,那么这组进程就处于死锁状态。
死锁特征 Deadlock Characterization
必要条件
- 互斥Mutual exclusion: 一次只有一个进程使用。如果另一进程申请该资源,那么申请进程必须等到该资源被释放为止。
- 占有并等待Hold and wait: 一个进程必须占有至少一个资源,并等待另一资源,而该资源为其他进程所占有。
- 非抢占No preemption: 资源不能被抢占,即资源只能在进程完成任务后自动释放。
- 循环等待Circular wait: A waits for B, B waits for C, C waits for A.
资源分配图
R为资源、P为进程。
申请边request edge – directed edge P1 → Rj
分配边assignment edge – directed edge Rj → Pi
如果资源分配图没有环,那么系统就不处于死锁状态。
如果有环,那么系统可能会处于死锁状态。
死锁处理方法 Methods for Handling Deadlocks
原理上,有三种处理死锁的办法:
- 可使用协议以预防或避免死锁,确保系统不会进入死锁状态。
- 死锁预防Prevention确保至少一个必要条件不成立(限制如何申请资源
- 死锁避免Avoidance操作系统事先得到有关进程申请资源和使用资源的额外信息。有了这些额外信息,系统可确定:对于一个申请,进程是否应等待。
- 可允许系统进入死锁状态,然后检测detect它,并加以恢复。
- 可忽视这个问题,认为死锁不可能在系统内发生。
死锁预防 Deadlock Prevention
互斥Mutual exclusion
一些可共享的资源必须是独占访问的(例如打印机),这意味着互斥条件是必须的。及有时我们难以改变互斥条件。
占有并等待Hold and wait
当一个进程申请一个资源时,它不能占有其他资源。两种策略:
- 每个进程在执行前申请并获得所有资源。
- 进程在没有资源时才能申请资源。(申请前要释放已有资源)
这两种策略会有两个缺点:
- Resource utilization资源利用率可能比较低,因为许多资源可能已分配,但是很长时间没有被使用。
- Starvation 一个进程如需要多个常用资源,可能会永久等待,因为其所需要的资源中至少有一个已分配给其他进程。
非抢占No preemption
如果一个进程占有资源并申请另一个不能立即分配的资源,那么其现已分配的资源都可被抢占。换句话说,这些资源都被隐式地释放了。
循环等待Circular wait
对所有资源类型进行完全排序,且要求每个进程按递增顺序来申请资源。要申请低级的资源,就必须释放已分配的高级资源。
一种特殊情况的占有并等待?
死锁避免 Deadlock Avoidance
死锁避免算法动态地检测资源分配状态以确保循环等待条件不可能成立(确保系统不会进入不安全状态)。
资源分配状态是由可用资源和己分配资源,及进程最大需求所决定的。
安全状态 Safe State
如果存在一个安全序列,那么系统处于安全状态。
安全序列:进程顺序<P1,P2,……,Pn>,如果对于每个Pi, Pi仍然可以申请的资源数小于当前可用资源加上所有进程Pj(其中j<i)所占有的资源,那么这一顺序称为安全序列。
在不安全状态下,操作系统不能阻止进程以会导致死锁的方式申请资源。进程行为控制了不安全状态。
银行家算法 Banker’s Algorithm
每种资源类型有多个实例。当新进程进入系统时,它必须说明其可能需要的每种类型资源实例的最大数量,这一数量不能超过系统资源的总和。当用户申请一组资源时,系统必须确定这些资源的分配是否仍会使系统处于安全状态。如果是,就可分配资源(进程得到资源后必须在有限时间内让出资源);否则,进程必须等待直到某个其他进程释放足够资源为止。
为了实现银行家算法,必须有几个数据结构。这些数据结构对资源分配系统的状态进行了记录。设n为系统进程的个数,m为资源类型的种类。需要如下数据结构:
- Availabe:长度为m的向量,表示每种资源的现有实例的数量。如果Availabe[j]=k,那么资源类型Rj现有k个实例。
- Max:n×m矩阵,定义每个进程的最大需求。如果Max[i][j]=k,那么进程Pi最多可申请k个资源类型Rj的实例。
- Allocation:n*m矩阵,定义每个进程现在所分配的各种资源类型的实例数量。如果Allocation[i][j]=k,那么进程Pi现在已分配了k个资源类型Rj的实例。
- Need:n*m矩阵,表示每个进程还需要的剩余的资源。Need=Max-Allocation。
安全性算法 Safety Algorithm
确定计算机系统是否处于安全状态
- 设Work和Finish分别为长度为m和n的向量。按如下方式进行初始化:Work=Available且对于i = 0,1,…,n-1, Finish[i]=false.
- 查找这样的i使其满足
- a.Finish[i] = false
- b.Needi≤Work
- 如果没有这样的i存在,那么就转到第④步。
- Work=Work + Allocationi Finish[i] = true 返回到第②步。
- 如果对所有i, Finish[i]=true,那么系统处于安全状态。
这个算法可能需要m*n^2 数量级的操作以确定系统状态是否安全。
资源请求算法
描述是否可安全允许请求的算法。
死锁检测 Deadlock Detection
此时系统应提供:
- 一个用来检查系统状态从而确定是否出现了死锁的算法。
- 一个用来从死锁状态中恢复的算法。
分每种资源类型有单实例、多实例进行讨论。
每种资源类型只有单个实例
需要一个等待图wait-for graph(资源分配图的变种)。
进程为节点,P_i ->P_j 表示pi要等待pj释放其所需的一个资源。
当且仅当等待图中有环,系统存在死锁。从图中检测环的算法复杂度为n^2 (n为结点个数)。
每种资源类型可有多个实例
需要如下数据结构:
- Availabe:长度为m的向量,表示每种资源的现有实例的数量。
- Allocation:n*m矩阵,定义每个进程现在所分配的各种资源类型的实例数量。
- Request:n*m矩阵,表示当前每个进程的资源请求情况。
银行家算法的need为进程还需要的总的资源
算法:
- 设Work和Finish分别为长度为m和n的矢量。初始化Work=Available。对i = 0,1,…,n-1,如果Allocationi不为0,则Finishi=false;否则,Finishi=true。
- 找这样的i,以便同时使
- Finishi=false
- Requesti≤Work
- 如果没有这样的i,则转到第④步。
- Work = Work+Allocationi, Finishi=true 转到第②步。
- 如果对某个i(0≤i<n),Finishifalse,则系统处于死锁状态。而且,如果Finishifalse。则进程Pi死锁。
该算法需要级操作m*n^2 来检测系统是否处于死锁状态。
应用检测算法
何时调用检测算法取决于:
- 死锁可能发生的频率
- 当死锁发生时,有多少进程会受影响
如果在不确定的时间点调用检测算法,那么资源图会有许多环。通常不能确定死锁进程中是哪些“造成”了死锁。
死锁恢复 Recovery from Deadlock
进程终止 Process Termination
有两种策略:
- 终止所有死锁进程。这种方法显然终止了死锁循环,但其代价也大。这些进程可能已计算了很长时间,这些部分计算结果必须放弃,以后可能还要重新计算。
- 一次只终止一个进程直到取消死锁循环为止。这种方法的开销会相当大,这是因为每次终止一个进程,都必须调用死锁检测算法以确定进程是否仍处于死锁。
如果采用了部分终止,那么对于给定死锁进程,必须确定终止哪个进程或哪些进程可以打破死锁。这个确定类似于CPU调度问题,是个策略选择。该问题基本上是个经济问题,应该终止代价最小的进程。然而,“代价最小”并不精确,许多因素都影响着应选择哪个进程,包括:
- 进程的优先级是什么?
- 进程已计算了多久,进程在完成指定任务之前还需要多久?
- 进程使用了多少什么类型的资源(例如,这些资源是否容易抢占)?
- 进程需要多少资源以完成?
- 多少进程需要被终止?
- 进程是交互的还是批处理的?
资源抢占 Resource Preemption
通过抢占资源以取消死锁,逐步从进程中抢占资源给其他进程使用,直到死锁环被打破。
有三个问题:
- 选择牺牲品victim。确定抢占顺序使代价最小
- 回滚rollback。将进程回滚到某个安全状态,以便从该状态重启进程。通常确定一个安全状态并不容易,所以最简单的方法是完全回滚:终止进程并重新执行。更为有效的方法是将进程回滚到足够打破死锁。另一方面,这种方法要求系统维护有关运行进程状态的更多信息。
- 饥饿。一些进程可能总是被选为牺牲品。应该在代价因素中加入回滚次数。
标签:状态,资源类型,Deadlocks,算法,死锁,ch7,进程,资源 来源: https://www.cnblogs.com/wozjr/p/16310407.html