精华内容
下载资源
问答
  • 安全状态死锁

    千次阅读 2018-11-28 21:48:19
    1.关于不安全状态死锁状态的不同之处:  1>:正如申老师所言,当进程处于不安全状态的时候,可能会由于操作系统在期间杀死一些进程等意外情况下而使不安全状态避免向死锁状态的转化。  2>:在我看来...

    1.关于不安全状态与死锁状态的不同之处:
      1>:正如申老师所言,当进程处于不安全状态的时候,可能会由于操作系统在期间杀死一些进程等意外情况下而使不安全状态避免向死锁状态的转化。
      2>:在我看来,1中的思想可能有点牵强,毕竟在大多数情况下进程都是可以正常结束的,而且书中银行家算法也是在所有的进程正常运行对前提上进行操作的。书中产生死锁的四个必要条件之不可抢占条件中写到。进程已获得的资源在进程未使用完之前不可被抢占,只能在进程使用完时由自己释放。注意:在这里是说进程使用完时自己释放,并不是进程结束时释放。所以,当进程组处于不安全状态时,是指找不到这样的一个安全序列,使得进程能按某种推进顺序,为每一个进程分配其所需资源,直至满足每一个进程对资源的最大需求,使得每一个进程都可以顺利完成。我们需要注意的是,这种假设是在这一刻完成的,即在推进过程的这一刻,进程必须满足它所需要的所有资源,而且也只有进程结束之后才将其所拥有的所有资源释放,我想这也是书中为什么说是“满足其最大需求”。实际上,可能在程序运行的过程中,在其下次申请资源之前,就可能释放其所拥有的部分资源,从而使系统处于安全状态,只有在最坏条件下(所有的进程都霸占其此时所拥有的资源并且去申请新的资源)才能导致死锁。

    展开全文
  • 图6-9a的状态安全的,这是由于存在一个分配序列使得所有的进程都能完成。也就是说,这个方案可以单独地运行B,直到它请求并获得另外两个资源实例,从而到达图6-9b的状态。当B完成后,就到达了图6-9c的状态。然后...

    在图6-9a中有一个A拥有3个资源实例但最终可能会需要9个资源实例的状态。B当前拥有2个资源实例,将来共需要4个资源实例。同样,C拥有2个资源实例,还需要另外5个资源实例。总共有10个资源实例,其中有7个资源已经分配,还有3个资源是空闲的。
    在这里插入图片描述
    图 6-9a

    图6-9a的状态是安全的,这是由于存在一个分配序列使得所有的进程都能完成。也就是说,这个方案可以单独地运行B,直到它请求并获得另外两个资源实例,从而到达图6-9b的状态。当B完成后,就到达了图6-9c的状态。然后调度程序可以运行C,再到达图6-9d的状态。当C完成后,到达了图6-9e的状态。现在A可以获得它所需要的6个资源实例,并且完成。这样系统通过仔细的调度,就能够避免死锁,所以图6-9a的状态是安全的。
    现在假设初始状态如图6-10a所示。但这次A请求并得到另一个资源,如图6-10b所示。我们还能找到一个序列来完成所有工作吗?我们来试一试。调度程序可以运行B,直到B获得所需资源,如图6-10c所示。
    最终,进程B完成,状态如图6-10d所示,此时进入困境了。只有4个资源实例空闲,并所有活动进程都需要5个资源实例。任何分配资源实例的序列都无法保证工作的完成。于是,从图6-10a到图6-10b的分配方案,从安全状态进入到了不安全状态。从图6-10c的状态出发运行进程A或C也都不行。回过头来再看,A的请求不应该满足。
    值得注意的是,不安全状态并不是死锁。从图6-10b出发,系统能运行一段时间。实际上,甚至有一个进程能够完成。而且,在A请求其他资源实例前,A可能先释放一个资源实例,这就可以让C先完成,从而避免了死锁。因而,安全状态和不安全状态的区别是:从安全状态出发,系统能够保证所有进程都能完成;而从不安全状态出发,就没有这样的保证。
    在这里插入图片描述

    展开全文
  • 操作系统中不安全状态为何并非一定转为死锁

    万次阅读 多人点赞 2020-01-31 12:26:41
    在学习避免死锁、银行家算法时,对于安全状态一定不会产生死锁,不安全状态也并非必然转为死锁,不止你是否会疑惑为何处于不安全状态下,不是必然会发生死锁

    ​ 这个问题出自与避免死锁中的安全状态和非安全状态,在讨论之前,先来解释下安全状态和非安全状态。

    1.系统安全状态

    ​ 所谓安全状态,是指系统能够按某种进程推进顺序(P1,P2,…,Pn)为每个进程分配其所需资源,直至满足每个进程对资源的最大需求,使每个进程都可顺利的执行完成。其中进程的推进顺序(P1,P2,…,Pn)被称为安全序列。如果系统中能找到这样一个安全序列,则称系统处于安全状态。

    ​ 如果系统中无法找到一个安全序列,则称系统处于不安全状态

    ​ 我们通过一个例子来说明安全性。假定系统中有三个进程P1、P2和P3,共有12台磁带机。进程P1总共要求10台磁带机,P2和P3分别要求4台和9台。假设在T0时刻,进程P1、P2和P3已分别获得5台、2台和2台磁带机,尚有3台空闲未分配,如下表所示:

    资源分配图

    ​ 对于上题,我们可以知道T0时刻系统是安全的,因为这是存在一个安全序列(P2,P1,P3)。

    ​ 如果不按照安全序列分配资源,则系统可能会有安全状态进入不安全状态。例如在T0时刻后T1时刻,P3又请求一台磁带机,如果此时分配资源给进程P3,此时的资源分配如下表所示:

    资源分配图

    ​ 我们可以看到,在T1时刻,无法找到一个安全序列,因此在T1时刻系统处于不安全状态。

    2.不安全状态和死锁的关系

    ​ 由上述描述,我们可以得出一个结论,只要系统处于安全状态,系统便不会进入死锁状态;但是另一句话:当系统处于不安全状态时,并非所有不安全状态都必然转换为死锁,就有点懵了。

    安全状态与不安全状态图

    ​ 对于系统处于不安全状态,为什么不是一定会转为死锁状态?按照死锁的发生的四个必要条件:互斥条件、请求和保持条件、不可抢占条件、循环等待条件,只要其中的一个条件不满足就不会发生死锁,这也是预防死锁的理论依据。如果系统中已经设置了预防死锁的策略,那么死锁就不会产生,也就不需要避免死锁算法了,因此,设置了避免死锁策略(或者说是银行家算法)的OS,应当不会破坏四个必要条件中的任一个,这样所施加的限制条件较弱,以期望获得更好的系统性能。

    ​ 由上面的描述,我就在想,如果系统处于安全状态,因为临界资源的不可抢占性,高优先级进程也无法剥夺已经分配出去的进程,那么系统是怎么样才可以让如何推进都无法顺利执行完毕的“死局”得到“一线生机”呢?

    ​ 经过自己的思考(通过结论推过程----’囧‘),和翻看了网上的许多讨论后,觉得以下几点是比较靠谱的:

    ​ 可能一:进程在执行过程中,可能会提前终止。当进程处于不安全状态的时候,因为OS当前资源紧缺或者进程执行过程发生异常,导致某些进程没有继续申请资源而被终止(被kill或异常终止),这样被终止的进程就会释放资源,让OS避开这次死锁。

    ​ 可能二:进程在正常运行过程中,可能会提前释放部分资源。这一点,可能有些同学会疑惑,是不是破坏了请求和保持条件?其实并没有破坏了请求和保持条件,因为破坏请求和保持条件,需要OS必须保证做到:当一个进程在申请资源时,不得持有任何不可抢占资源,所以进程释放掉自己持有的部分资源是没有破坏请求和保持条件的。

    ​ 可能三:进程实际需要的最大资源小于声明的最大需求资源。在安全性检查算法中,使用的数据结构是需求矩阵Need和当前资源数Available,Need由最大需求矩阵Max减去已经分配的Allocation求得,Max是进程事先对自身所需资源的一个最坏情况下的预估(因为要满足运行,必定是>=实际需要的),但是在实际执行的情况中,可能进程实际上用不到这么多的资源,所以有可能就是这相差的资源数可以保证系统并非必然转换为死锁。

    ​ 可能四:进程申请的资源为可消耗性资源。这一点可能许多同学会懵,怎么还跑出了这么一个可消耗性资源的事,我们在资源分类的时候就讲过,资源分为可重用性资源和可消耗性资源,对于可消耗性资源,是可以在进程运行过程中产生的(比如消息),因此对于某些阻塞的进程,虽然当前资源不足,但有可能在有限的时间内可以申请到得以运行完成的资源(可消耗性资源,由别的进程执行过程中产生),因此可以释放掉自己持有的资源,让其他进程因此也可以执行完毕。

    ​ 以上四点是我个人总结的几点原因,个人感觉每种可能都对,查看外文文档,解释偏向于可能三,不过博主自己觉得一、二、四也是对的,毕竟答案不唯一,理论上可行就可以是答案。

    3.总结

    ​ 以上所有观点都是自己的个人观点,如果有哪位大佬有不同的看法或者还有可能五、六、七,都欢迎评论区留言讨论,还请不吝赐教。


    ​ 又到了分隔线以下,本文到此就结束了,本文内容全部都是由博主自己进行整理并结合自身的理解进行总结,如果有什么错误,还请批评指正。

    ​ 本文纯属探讨理论上的可能,另,原创不易,如果能解答你的疑惑,还请点赞支持。

    ​ 如有兴趣,还可以查看我的其他几篇博客,都是OS的干货,喜欢的话还请点赞、评论加关注^_^。

    操作系统武功修炼心法

    展开全文
  • 死锁

    2020-03-04 17:00:08
    死锁死锁死锁特征死锁的必要条件资源分配图死锁处理方法死锁预防互斥占有并等待非抢占循环等待死锁避免安全状态 死锁 死锁特征 死锁的必要条件 如果在一个系统中下面4个条件同时满足,那么会引起死锁。 1.互斥:至少...

    死锁

    死锁特征

    死锁的必要条件

    如果在一个系统中下面4个条件同时满足,那么会引起死锁。
    1.互斥:至少有一个资源必须处于非共享模式。
    2.占有并等待:一个进程必须占有至少一个资源,并等待另一资源。
    3.非抢占:资源不能被抢占,即资源只能在进程完成任务后自动释放。
    4.循环等待:有一组等待进程{P1,P2,…,Pn},P1等待的资源被P2所占有,P2等待的资源被P3所占有,…,Pn等待的资源被P1所占有。

    资源分配图

    死锁问题可用称为系统资源分配图的有向图进行更为精准地描述。这种图由一个节点集合V和一个边集合E组成。节点集合V可分成两种类型的节点:P={P1,P2,…,Pn}(系统活动进程的集合)和R={R1,R2,…,Rm}(系统所有资源类型的集合)。

    由活动进程Pi到资源类型Rj的有向边记为Pi -> Rj,它表示进程Pi已经申请了资源类型Rj的一个实例,并正在等待该资源。由资源类型Rj到进程Pi的有向边记为
    Rj -> Pi,它表示资源类型Rj的一个实例已经分配给进程Pi。Pi -> Rj称为申请边,Rj -> Pi称为分配边

    资源分配图

    根据资源分配图的定义,可以证明:如果分配图没有环,那么系统就没有进程死锁。如果分配图有环,那么可能存在死锁。


    死锁处理方法

    从原理上来说,有三种方法可处理死锁:
    1.可用使用协议以预防或避免死锁,确保系统不会进入死锁。
    2.可允许系统进入死锁,然后检测它加以修复。
    3.忽视该问题,认为死锁不可能发生

    死锁预防(deadlock prevention)是一组方法,以确保至少一个必要条件不成立。

    死锁避免(deadlock avoidance)要求操作系统事先得到有关进程申请资源和使用资源的额外信息。


    死锁预防

    通过对死锁产生的四个必要条件进行研究,找到预防死锁的办法。

    互斥

    如果资源是共享的,比如说只读文件,那么对这类型的资源的访问是不会造成死锁的。但很多资源本身就是非共享资源,所以通常不能通过否定互斥这一条件来预防死锁。

    占有并等待

    为了确保占有并等待的情况不在系统内出现,必须保证:当一个进程申请资源时,本身不能占有任何资源(进程不占有资源);或者,进程在执行前申请并获得所有资源(进程不等待资源)。

    这种做法由两个主要缺点:
    1.资源利用率低
    2.可能造成饥饿

    非抢占

    为了确保这一条件不成立,可以使用如下协议:如果一个进程占有资源并申请另一个不能立即分配的资源,那么其现已分配的资源都可被抢占。

    这个协议通常应用于状态可用保存和恢复的资源,如CPU寄存器和内存。因为等待的进程取得期望资源后要将被抢占的资源恢复在继续执行。

    循环等待

    一个确保此条件不成立的方法是对所有资源类型进行完全排序,且要求每个进程按递增顺序来申请资源。一个进程开始可申请任何数量的资源类型Ri的实例,之后,当且仅当F(Rj) > F(Ri)时(F函数返回资源类型的等级),该进程可以申请资源Rj的实例。如果进程需要同一资源类型的多个实例,那么对它们必须一起申请。

    换句话说,要求当一个进程申请资源类型Rj时,它必须释放所有资源Ri(F(Ri) >= F(Rj))。


    死锁避免

    死锁预防的副作用是降低了设备使用率和系统吞吐率。

    通过获得进程以后如何申请资源的附加信息,可用通过算法来避免死锁。

    不同的算法对于要求的信息量和信息的类型有所不同。最为简单和最为有用的模型要求每个进程说明可能需要的每种资源类型实例的最大需求。根据这些事先信息,可用构造一个算法以确保系统不会进入死锁状态。

    死锁避免算法动态地检测资源分配状态以确保循环等待条件不可能成立。

    安全状态

    如果系统能按某个顺序为每个进程分配资源(不超过其最大值)并能避免死锁,那么系统状态就是安全的,这个顺序称为安全序列

    进程顺序<P1,P2,…,Pn>,如果对于每个Pi,Pi需要申请的资源数小于当前可用资源加上所有进程Pj(j < i)所占有的资源(同一资源类型),那么这一顺序称为安全序列。如果没有这样的顺序存在,那么系统状态就处于不安全状态(可能陷入死锁)。

    举个例子:

    进程最大需求当前需求
    P0105
    P142
    P292

    如表所示,假设在t0时刻,总共有12台打印机,P0 占有了5台打印机,P1占有了2台打印机,P2占有了2台打印机,还有3台打印机空闲。那么顺序<P1,P0,P2>就是安全序列。进程P1,可以立即获得所需的两台打印机,然后将4台打印机释放,P0,P2同理。

    系统可以从安全状态转换为不安全状态。假定在时刻t1,P2申请并又得到了1台打印机,就不会存在所谓的安全序列了。

    有了安全状态的概念,可定义避免算法以确保系统不会死锁。只有资源分配后使系统仍处于安全状态的资源申请才会被允许。

    资源分配图算法

    如果每种资源类型只有一个实例,那么资源分配图有环就死锁,无环就没有死锁,那么通过避免环的产生,就能避免死锁的产生。

    银行家算法

    对于每种资源类型有多个实例的资源分配系统,资源分配图算法就不适用了。银行家算法能够解决这种问题。

    当新进程进入系统时,它必须说明其可能需要的每种类型资源实例的最大数量,这一数量不能超过系统资源的总和。当用户申请一组资源时,系统必须确定这些资源的分配是否仍会使系统处于安全状态。

    为了实现银行家算法,必须有几个数据结构。这些数据结构对资源分配系统的状态进行了记录。设n为系统进程的个数,m为资源类型的种类。需如下数据结构:
    1.Available,长度为m的向量,表示每种资源的现有实例的数量。
    2.Max,n×m矩阵,定义每个进程的最大需求。
    3.Alloction,n×m矩阵,定义每个进程所在所分配的各种资源类型的实例数量。
    4.Need,n×m矩阵,表示每个进程还需要的剩余资源。
    Need[i][j] = Max[i][j] - Alloction[i][j]

    这些数据结构的大小和值会随着时间而改变。

    安全性算法

    确定计算机系统是否处于安全状态的算法分为如下几步:

    1.设 Work 和 Finish 分别为长度为 m 和 n 的向量。按如下方式进行初始化,
    Work = Available 且 对于 i = 0,1,…,n-1,Finish[i] =false。

    2.查找这样的 i 使其满足
    a.Finish[i] == false
    b. Need i <= Work (Need i 表示Need矩阵中下标为 i 那一行向量)
    如果没有这样的 i 存在,那么转到第四步。

    3.Work = Work + Allocation i
    Finish[i] = true
    返回到第二步。

    4.如果对所有i,Finish[i] = true,那么系统处于安全状态。

    这个算法可能需要 m × n^2 数量级的操作以确定系统状态是否安全(相当于寻找计算机系统中是否存在安全序列)。

    资源请求算法

    设 Request i 为进程Pi的请求向量。如果 Request i[j] == k,那么进程Pi需要的资源类型 Rj 的实例数量为 k。当进程Pi作出资源请求时,采取如下动作:

    1.如果 Request i <= Need i,那么转到第二步。否则产生出出错条件,这是因为进程Pi已超过了其最大请求。

    2.如果 Request i <= Available,那么转到第三步。否则Pi必须等待,这是因为没有可用资源。

    3.假定系统可用分配给进程Pi所请求的资源,并按如下方式修改状态:
    Available = Available - Request i;
    Allocation i = Allocation i + Request i;
    Need i = Need i - Request i;

    如果所产生的资源分配状态是安全的,那么交易完成且进程Pi可分配到其所需要资源。然而,如果新状态不安全,那么进程Pi必须等待Request i并恢复到原来资源分配状态。


    死锁检测

    如果一个系统既不采用死锁预防算法也不采用死锁避免算法。那么可能会出现死锁。在这种环境下,系统应提供:
    1.一个用来检查系统状态从而确定是否出现了死锁的算法。
    2.一个用来从死锁状态中恢复的算法。

    每种资源类型只有单个实例

    如果所有资源类型只有单个实例,那么可以定义这样一个死锁检测方法,该算法使用了资源分配图的一个变种,称为等待图。从资源分配图中,删除所有资源类型节点,合并适当边,就可以得到等待图。

    与以前一样,当且仅当等待图中有一个环,系统中存在死锁。

    每种资源类型可有多个实例

    同样,我们需要一些数据结构:
    1.Available: 长度为m的向量,表示各种资源的可用实例。
    2.Allocation:n×m矩阵,表示当前个进程的资源分配情况。
    3.Request:n×m矩阵,表示当前各进程的资源请求情况。

    检测步骤如下:

    1.设 Work 和 Finish 分别为长度为 m 和 n 的向量。初始化 Work = Available。对于 i = 0,1,…,n - 1,如果 Allocation i 不为0,则 Finish[i] = false;否则,Finish[i] = true。

    2.找到这样的 i,以便同时使
    a.Finish[i] == false
    b.Request i <= Work
    如果没有这样的 i,则转到第四步。

    3.Work = Work + Allocation i
    Finish[i] = true
    转到第二步

    4.如果对某个 i(0 <= i < n),Finish[i] == false,则系统处于死锁状态。而且,如果 Finish[i] == false。则进程Pi死锁。

    应用检测算法

    应该何时调用检测算法?答案取决于两个因素:
    1.死锁可能发生的频率是多少?
    2.当死锁发生时,有多少进程会受影响?

    如果经常发生死锁,那么就应该经常调用检测算法。以一个不太高的频率调用检测算法,如每小时一次,或当CPU使用率低于40%s时(死锁最红会使系统性能下降,并造成CPU使用率下降)。


    死锁恢复

    进程终止

    有两种方法通过终止进程已取消死锁。
    1.终止所有死锁进程。
    2.一次只终止一个进程直到取消死锁循环为止。

    资源抢占

    通过抢占资源以取消死锁,逐步从进程中抢占资源给其他进程使用,直到死锁环被打破。

    展开全文
  • Linux:死锁避免之系统安全状态

    千次阅读 2018-04-23 21:22:06
    死锁避免方法之一:判断系统安全状态 避免死锁的方法中,允许进程动态地申请资源,但系统在进行资源分配之前,应先计算此次资源分配的安全性。若此次分配不会导致系统进入不安全状态,则将资源分配给进程; 否则...
  • P1和P2形成一个环形,所以我们说它产生了死锁,这个图也是不安全状态。因为当P2申请一台输入设备时,输入设备已经分配给了P1,这就导致P2一直处于申请状态,当输出设备要分配给P2的时候,P2在申请,输出设备也就一直...
  • 死锁相关

    2018-06-25 22:04:44
    1.四个必要条件:互斥:一段时间内某资源只能被一个进程占有不剥夺:进程获得的资源在未使用完毕...死锁的处理预防死锁:破坏四个必要条件中的其中一个避免死锁:银行家算法,阻止进入不安全状态死锁的检测与解除:...
  • /** * 什么是锁机制?什么是死锁?...* 说明:出现死锁后,不会出现异常,不会出现提示只是所有线程都处于阻塞状态,无法连接 */ 运行一次: 运行两次: 这个时候就出现了死锁状态 ...
  • 操作系统中判断当前是否是安全状态和是否有死锁进程的算法比较类似,请说明二者之间的区别?

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 95,332
精华内容 38,132
关键字:

安全状态死锁