第3章 3-3死锁 银行家算法

关于死锁

        多道程序系统借助并发执行改善资源利用率,提高系统吞吐量,但可能发生一种危险——死锁。

        死锁(Deadlock):指多个进程在运行过程中,因争夺资源而造成的一种僵局。当进程处于这种状态时,若无外力作用,它们都将无法再向前推进。

        死锁(Deadlock): 指进程之间无休止地互相等待!

        饥饿(Starvation):指一个进程无休止地等待!

四、产生死锁的原因和必要条件

        产生死锁的原因可归结为如下两点:

                竞争资源。系统中供多个进程共享的资源如打印机、公用队列等的数目不满足需要时,会引起资源竞争而产生死锁。

                进程间推进顺序非法。进程在运行过程中,请求和释放资源的顺序不当,同样会导致死锁。

1、竞争资源引起进程死锁

        可把系统中的资源分为两类:

                可剥夺和非剥夺性资源

                        可剥夺性资源:分配给进程后可以被高优先级的进程剥夺。如CPU和主存。

                        不可剥夺性资源:分配给进程后只能在进程用完后释放。如磁带机、打印机等。

                永久性资源和临时性资源

                        永久性:打印机。可顺序重复使用

                        临时性:进程产生被其他进程短暂使用的资源,如数据资源:“生产者/消费者”算法中的信号量。它可能引起死锁。

2、进程推进顺序不当引起死锁

        进程在运行中具有异步性特征,多个进程按向前推进的顺序有两种情况:

                ①推进顺序合法

                ②推进顺序非法

3、 产生死锁的必要条件

        形成死锁的四个必要条件(四个条件都具备就会死锁,缺一就不会死锁)

                互斥条件:进程对所分配到的资源进行排他性使用

                请求和保持条件:进程已经保持了至少一个资源,又提出新的资源请求,而新请求资源被其他进程占有只能造成自身进程阻塞,但对自己已获得的其他资源保持不放,必然影响其他进程。

                不剥夺条件:进程已获得的资源未使用完之前不能被剥夺,只能在使用完时由自己释放。

                环路等待条件

        破坏这4个条件即是处理死锁的方法

4、处理死锁的基本方法

        事先预防:

                ①预防死锁

                        设置限制条件,破坏四个必要条件的一个或几个,预防发生死锁。

                        较易实现。限制条件的严格也会导致系统资源利用率和系统吞吐量降低。

                ②避免死锁

                        不须事先限制,破坏四个必要条件,而是在资源的动态分配过程中,用某种方法去防止系统进入不安全状态,从而避免发生死锁。

                        这种事先加以较弱限制的方法,实现上有一定难度,但可获较高的资源利用率及系统吞吐量,目前在较完善的系统中,常用此方法来避免发生死锁。

        事后处理:

                ③检测死锁。

                        允许系统运行过程中发生死锁,但通过系统检测机构可及时的检测出,能精确确定与死锁有关的进程和资源;然后采取适当的措施,从系统中将已发生的死锁清除掉。

                ④解除死锁。

                        与死锁检测配套的一种措施。

                        常用的实施方法:撤销或挂起一些进程,以便回收一些资源并将他们分配给已阻塞进程,使之转为就绪以继续运行。

                        死锁的检测与解除措施,有可能使系统获得较好的资源利用率和吞吐量(死锁几率不一定很高),但在实现上难度也最大。

五、预防死锁的方法

1.预防死锁

        资源的排他性无法更改,故在其他3个条件上入手

                ①摒弃“请求和保持”条件:所有进程开始运行前,必须一次性的申请其在整个运行过程所需的全部资源(AND)。算法简单、易于实现且很安全。但缺点是资源浪费严重、或进程延迟运行。

                ②摒弃“不剥夺”条件:允许进程先运行,但当提出的新要求不被满足时必须释放它已保持的所有资源,待以后需要时再重新申请。实现比较复杂且付出很大代价。可能会造成前功尽弃,反复申请和释放等情况。

                ③摒弃“环路等待”条件

                        有序设置资源:将所有资源按类型进行线性排队,赋予不同序号。所有进程对资源的请求必须严格按照资源序号递增的次序提出,这样在所形成的资源分配图中,不可能会出现环路。

                        与前两种策略比较,资源利用率和系统吞吐量都有较明显的改善。但也存在严重问题:

                                资源编号限制新设备的增加;

                                应用中的使用设备顺序与规定的顺序并不协调;

                                限制了用户编程自由。

2.避免死锁

        上述方法限制条件都太强;造成一定的应用不便。采用避免死锁的方法则是只施加较弱限制条件,从而获得令人满意的系统性能。

        名词:

        安全状态:系统能按某种进程顺序为每个进程分配所需资源,直至满足每个进程对资源的最大需求,并能顺利完成。

        不安全状态:系统无法找到一种使多个进程能够顺利分配资源执行完的安全序列。

安全状态、

安全序列举例

由安全状态向不安全状态的转换

        每次资源分配时,都应分析判断资源分配图,看该次操作后是否有安全序列。若没有,说明该操作会使系统进入不安全状态。

        只要使系统始终处于安全状态,便可避免发生死锁。

        不是所有的不安全状态都是死锁状态。

3. 银行家算法避免死锁

        最有代表性的避免死锁的算法,是Dijkstra的银行家算法。由于该算法能用于银行系统现金贷款的发放而得名。

        【思路描述】:随时对系统中的所有资源信息进行统计,包括每种资源的数量、已分配给各进程的数量;每当进程提出某种资源请求时判断该请求分配后是否安全,如果安全才分配。对每个资源请求的处理都要保证系统始终从一个安全状态到另一个安全状态。

算法实现说明

        算法实现:

                首先:需要的一些数据结构

                再次:算法过程

                核心:安全性判断算法

        1)银行家算法中的数据结构

                (1)各类可利用资源的数量

                        向量Available :(i1,i2,…,im),含m个元素,每个元素代表一类可利用的资源数目。

                        动态变化的,初始值是系统配置的该类资源的全部数目,值随资源的分配与回收而动态的改变。

                        实现:一维数组。Available【j】=K,表示系统中Rj类资源现有可用数量为K个。

                (2)每个进程对每类资源的需求

                        最大需求、已获得的、还需要的

                        ①最大需求矩阵Max

                        n*m,系统中n个进程中每个进程分别对m类资源的最大需求。

                        取值:根据进程需求赋初始值。

                        实现:二维数组。Max【i,j】=K,表示进程 i 需要Rj类资源的最大数目为K。

                        ②已分配矩阵Allocation。

                        n*m,定义系统中每一进程已获得的每类资源数量。

                        Allocation【i,j】=K,表示进程i当前已分得Rj类资源数为K。

                        ③还需求的矩阵Need。

                        n*m,表示每一进程尚需的各类资源数。

                        Need【i,j】=K,表示进程i还需要Rj类资源K个,方能完成任务。

                        上述三个矩阵存在关系:

                                Max【i,j】= Allocation【i,j】+Need【i,j】

                                每次,给进程 i 分配资源的动作,影响上述数据结构的取值:

                                Available【  】,Allocation【i,】,Need【i,】

        2)避免死锁的算法过程(银行家算法)

算法过程:就是对各进程的Request向量及资源数量进行一系列判断及值操作。

进程Pi发出资源请求后,系统按下述步骤进行检查:

首先是两个基本判断:

(1)IF Requesti[j]<= Need[i,j]

        THEN 转向步骤2;

        ELSE 认为出错,所需资源数超过宣布的最大值(自我矛盾)

(2)IF Requesti[j]<= Available[j]

            THEN 转向步骤3;

            ELSE 表示尚无足够资源,Pi需等待(现实不满足)

        3)安全性算法

                (1)需要一些记录信息的数据结构,设置两个向量:

                        工作向量work

                                算法开始时work=Available;

                                系统找安全序列的过程需要不断判断和修改当前资源数量,不能直接修改原始数据记录Aailable。

                        标志向量Finish

                                    表示每个进程是否有足够的资源使之运行完成。开始时所以进程都设置初值Finish[i]:=false;

                                    找安全序列的过程相当于使所有Finish[i]:=true。

                (2)找安全序列的过程

                        从 Finish[i] = false 的进程集合中找一个进程

                        IF Need[i,j] <= work[j]

                                THEN  执行步骤 a;

                                ELSE  执行步骤 b;

                        a) 假设Pi获得资源顺利执行完,释放出分配给它的资源,修改相应的值:

                                    work【j】  = work【i】+ Allocation【i,j】;

                                    Finish【i】= true;

                                    goto step (2); //返回去继续找下一个进程。

                        b)当算法不再在(2)、a)步间循环找进程,到达本步时,若所有Finish[i]=true都满足,则表示所有进程都按某个顺序执行完了,系统处于安全状态;否则,系统当前所处的资源分配状态是不安全状态。

六、死锁的检测与解除

当系统为进程分配资源时,若未采取任何限制性措施,则系统必须提供检测和解除死锁的手段,为此系统必须:

        1.保存有关资源的请求和分配信息;

        2.提供一种算法,以利用这些信息来检测系统是否已进入死锁状态。

1、资源分配图

        系统死锁可利用资源分配图来描述。

        圆圈表示进程

        方框表示一类资源,其中的一个代表一个该类资源

        请求边由进程指向方框中的资源

        分配边则由方框中的一个点即资源。

死锁的检测

        检测时机:

                当进程等待时检测死锁

                定时检测

                系统资源利用率下降时检测死锁

2、死锁定理

        利用资源分配图简化法来检测死锁。

        简化方法如下:

        (1)在资源分配图中找出一个既不阻塞又非独立的进程结点Pi,在顺利的情况下运行完毕,释放其占有的全部资源。

        (2)由于释放了资源,这样能使其它被阻塞的进程获得资源继续运行。消去了Pi的边。

        (3)经过一系列简化后,若能消去图中所有边,使结点都孤立,称该图是可完全简化的。

        S状态为死锁状态的充分条件是当且仅当S状态的资源分配图是不可完全简化的。<死锁定理>

每类资源只有一个资源

死锁检测算法:

* 每个进程和资源指定唯一编号

* 设置一张资源分配表

记录各进程与其占用资源之间的关系

* 设置一张进程等待表

记录各进程与要申请资源之间的关系

反复检测这两张表,列出所有等待与分配的关系,若出现循环等待,则出现了死锁!

3、 死锁的解除

        当发现进程死锁时,便应立即把它们从死锁状态中解脱出来。常采用的方法是:

        ①剥夺资源。从其他进程剥夺足够数量的资源给死锁进程以解除死锁状态。

       ② 撤销进程。最简单的是让全部进程都死掉;温和一点的是按照某种顺序逐个撤销进程,直至有足够的资源可用,使死锁状态消除为止。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,948评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,371评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,490评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,521评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,627评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,842评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,997评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,741评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,203评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,339评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,955评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2 349

推荐阅读更多精彩内容