[OS] 死锁相关知识点以及银行家算法详解
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[OS] 死锁相关知识点以及银行家算法详解相关的知识,希望对你有一定的参考价值。
因此我们先来介绍一下死锁:
死锁特征
当出现死锁时,进程永远不能完成,并且系统资源被阻碍使用,阻止了其他作业开始执行。在讨论处理死锁问题的各种方法之前,先深入讨论一下死锁的特征。
·必要条件
(1)互斥:至少有一个资源必须处于非共享模式,即一次只有一个进程使用。如果另一进程申请该资源,那么申请进程必须等到该资源被释放为止。
(2)占有并等待:一个进程必须占有至少一个资源,并等待另一资源,而该资源为其他进程所占有。
(3)非抢占:资源不能被抢占,即资源只能在进程完成任务后自动释放。
(4)循环等待:有一组等待进程{P0,P1,···,Pn},P0等待的资源为P1所占有,P1等待的资源为P2所占有,...,Pn-1等待的资源为Pn所占有,Pn等待的资源为P0所占有。
注:强调所有4个条件必须同时满足才会出现死锁。循环等待意味着占有并等待,这样四个条件并不完全独立。但是,在下面的讨论中我们会看到分开考虑这些条件是有意义的。
·资源分配图
死锁问题可用系统资源分配图的有向图进行更为精确的描述。这种图由一个结点集合V和一个边集合E组成。
由进程Pi到资源类型Rj的有向边记为Pi->Rj,称为申请边,它表示进程Pi已经申请了资源类型Rj的一个实例,并在等待该资源。由资源类型Rj到进程Pi的有向边记为Rj->Pi,称为分配边,它表示资源类型Rj的一个实例已经分配给进程Pi。
在图上,用圆形表示进程Pi,用矩形表示资源类型Rj。由于资源类型Rj可能有多个实例,所以在矩形中用圆点表示实例。注意申请边只指向矩形Rj,而分配边必须指定矩形内的某个圆点。
根据分配图的定义,可以证明:如果分配图没有环,那么系统就没有进程死锁,如果分配图有环,那么可能存在死锁。
存在死锁的资源分配图 存在环但没有死锁的资源分配图
由上图可知,资源分配图有环不一定会产生死锁。
死锁处理方法
·可使用协议以预防或避免死锁,确保系统不会进入死锁状态。
·可允许系统进入死锁状态,然后检测它,并加以恢复。
·可忽视这个问题,认为死锁不可能在系统内发生。
死锁预防
我们已经知道,出现死锁要满足4个必要条件,只要确保一个必要条件不成立,就能预防死锁发生。下面通过讨论这4个必要条件来研究死锁预防方法。
互斥:共享资源不是必须的,而非共享资源必须保持互斥
占有并等待:必须保证进程申请资源的时候没有占有其他资源
·要求进程在执行前一次申请全部的资源,只有没有占有资源时才可以分配资源
·利用率低,可能出现饥饿
非抢占:如果一个进程的申请没有实现,它要释放所有占有的资源
循环等待:将所有的资源类型放入资源列表中,并且要求进程按照资源表中递增的顺序申请资源
死锁避免
上面我们讨论的死锁预防算法中,通过限制资源申请的方法来预防思索。这种限制确保4个必要条件之一不会发生,因此死锁不成立。然而,通过这种方法预防死锁的副作用是低设备使用率和系统吞吐率。
·安全状态
系统安全指存在一个执行序列,所有进程都能完成,这个序列被称为安全序列。下面来举一个例子:
系统有三个进程P1、P2和P3,共有12台打印机。 进程P1总共要求10台打印机,P2和P3分别要求4台和9台 假定T0时刻,进程P1、P2和P3已分别获得5台、2台和2台,尚有3台空闲未分,如下表:
可以看出,存在一个安全序列P2、P1、P3,所以说T0时刻是系统安全的。
安全状态不是死锁状态。相反,死锁状态是不安全状态。然而,不是所有不安全状态都能导致死锁状态。不安全状态可能导致死锁。系统可以从安全状态转换为不安全状态。
有了安全状态的概念,可定义避免算法以确保系统不会死锁。其思想是简单地确保系统始终处于安全状态。开始,系统处于安全状态。当进程申请一个可用的资源时,系统必须确定这一资源申请是可以立即分配还是等待。只有分配后使系统仍处于安全状态,才允许申请。
采用这种方案,如果进程申请一个现已可用的资源,那么它可能必须等待。因此,与没有采用死锁避免算法相比,这种情况下资源使用率可能更低。
·资源分配图算法(适用于每种资源类型只有一个实例)
该算法是在资源分配图的基础上,引入一新类型的边,称为需求边。需求边Pi->Rj表示进程Pi可能在将来某个时候申请资源Rj。这种边类似于同一方向的申请边,但用虚线表示。当申请资源时,需求边变为申请边;释放资源时,申请边变为需求边。
假设进程Pi申请资源Rj。只有在将申请边Pi->Rj变为分配边Rj->Pi而不会导致资源分配图形成环时,才允许申请。
·银行家算法(适用于每种资源类型有多个实例)
为了实现银行家算法,必须要有几个数据结构:
注:设n为系统进程的个数,m为在资源类型的种类。
Available:长度为m的向量。表示每种资源的现有实例的数量。如果Available[j]=k,那么资源Rj有k个实例有效。
Max:n * m矩阵。定义每种进程的最大需求。如果Max[i][j]=k,那么进程Pi可以最多请求资源Rj的k个实例。
Allocation:n * m矩阵。定义每个进程现在所分配的各种资源类型的实例数量。如果Allocation[I,j]=k,那么进程Pj当前分配了k个资源Rj的实例。
Need:n * m矩阵。表示每个进程还需要的剩余的资源。如果Need[i][j]=k,那么进程Pj还需要资源Rj的k个实例。
注:Need[i][j] = Max[i][j] – Allocation [i][j]
为了描述方便,我们采用一些简化的表示方法:
设X和Y为长度为n的向量,则X <= Y当且仅当对所有i = 1,2,...,n,X[i] <= Y[i]。例如,如果X = (1,7,2,3)而Y = (0,3,2,1),那么Y <= X。如果Y <= X且Y != X,那么Y < X。
可以将Allocation和Need的每行作为向量,并分别用Allocation i和Need i来表示,向量Allocation i表示分配给进程Pi的资源;向量Need i表示进程为完成其任务可能仍然需要申请的额外资源。
银行家算法可整体分成两个部分:
1.安全性算法
确认计算机系统是否处于安全状态的算法分为如下几步:
(1)设Work和Finish分别为长度为m和n的向量。按如下方式进行初始化,Work = Avaliable且对于i = 0,1,...,n - 1,Finish[i] = false。
(2)查找这样的i使其满足
·Finish[i] = false
·Need i <= Work
如果没有这样的i,那么就转到第(4)步。
(3)Work = Work + Allocation i
Finish[i] = true
返回第(2)步
(4)如果对所有i,Finish[i] = true,那么系统则处于安全状态。
该算法可能需要m * n^2数量级的操作以确定系统是否处于安全状态。
2.资源请求算法
现在,描述如何判断是否可安全允许请求的算法。
设Request i为进程Pi的请求向量。如果Request i[j] == k,那么进程Pi需要资源类型Rj的实例数量为k。当进程Pi作出资源请求时,采取如下动作:
(1)如果Request i <= Need i,那么转到第(2)步。否则,产生出错条件,这是因为进程Pi已超过了其最大请求。
(2)如果Request i <= Available,那么转到第(3)步。否则,Pi必须等待,这是因为没有可用资源。
(3)假定系统可以分配给进程Pi所请求的资源,并按如下方式修改状态:
Available = Available - Request i;
Allocation i = Allocation i + Request i;
Need i = Need i - Request i;
如果所产生的资源分配状态是安全的(通过上面的安全性算法),那么Pi可分配到它所请求的资源。但是,如果新状态不安全,则进程Pi必须等待Request i并恢复到原来的资源分配状态。
上面都是一些表达式,可能有些枯燥,现在我们来练习一道例题:
考虑这样一个系统,有5个进程P0~P4,3种资源类型A、B、C。资源类型A有10个实例,资源类型B有5个实例,资源类型C有7个实例。假定在时刻T0,系统状态如下:
Allocation Max Avaliable A B C A B C A B C P0 0 1 0 7 5 3 3 3 2 P1 2 0 0 3 2 2 P2 3 0 2 9 0 2 P3 2 1 1 2 2 2 P4 0 0 2 4 3 3
矩阵Need的内容定义成Max-Allocation:
Need A B C P0 7 4 3 P1 1 2 2 P2 6 0 0 P3 0 1 1 P4 4 3 1
可认为系统现在处于安全状态,因为存在一个安全序列<P1,P3,P4,P2,P0>。
现在假定进程P1再请求1个A类资源和两个C类资源,这样Request1 = (1,0,2)。为了确定这个请求是否可以立即允许,首先检测Request1 <= Available(即,(1,0,2) <= (3,3,2)),其值为真。接着假定这个请求被满足,会产生如下新状态:
Allocation Need Avaliable A B C A B C A B C P0 0 1 0 7 4 3 2 3 0 P1 3 0 2 0 2 0 P2 3 0 2 6 0 0 P3 2 1 1 0 1 1 P4 0 0 2 4 3 1
必须确定这个状态是否安全。为此,执行安全算法,并找到顺序<P1,P3,P4,P0,P2>满足安全要求。因此,可以立即允许进程P1的这个请求。
然而,可以发现当系统处于这一状态时,是不能允许P4的请求(3,3,0)的,因为没有那么多资源可用。也不能允许P0的请求(0,2,0);虽然有资源可用,但是这会导致系统处于不安全状态。
以上是关于[OS] 死锁相关知识点以及银行家算法详解的主要内容,如果未能解决你的问题,请参考以下文章