操作系统--银行家算法详解


银行家算法( banker's algorithm )由 Dijkstra(1065)提出。他将死锁的问题演示为一个银行家贷款的模型。
一个银行家向一群客户发放信用卡,每个客户有不同的信用额度。每个客户可以提出信用额度内的任意额度的请求,直到额度用完后再一次性还款。银行家承诺每个客户最终都能获得自己需要的额度。
所谓“最终”,是说银行家可以先挂起某个额度请求较大的客户的请求,优先满足小额度的请求,等小额度的请求还款后,再处理挂起的请求。这样,资金能够永远流通。
银行家算法可以用以下图表表示:
blob.png

每个客户和银行家都有交易限额。银行家只能和限额小于自己限额的客户进行交易。一旦银行家的限额小于所有客户的限额,便发生了死锁。
如上图所示。银行家分别和客户1,客户2,客户3进行了交易。第一次交易时,所有客户的限额都小于银行家的限额,任何客户都可以实现借款;第二次交易时,客户3的限额大小银行家的限额,这时银行家会挂起客户3 的请求;第三次交易时,只有客户3可以进行交易,其它的交易都会被挂起。直到客户3还款后,银行家才会考虑处理其它客户的交易。

银行家算法其核心是:保证自己的限额至少不小于一个客户的限额。



实例列举:

假定系统中有五个进程{P0, P1, P2, P3, P4}和三类资源{A, B, C},各种资源的数量分别为10、5、7,在T0时刻的资源分配情况如图所示。

      表1 T0时刻的资源分配表


MAXAllocationNeedAvailable
P0           7 5 3        0 1 0        7 4 3         3 3 2        
P13 2 2    2 0 01 2 2     
P29 0 23 0 26 0 0
P32 2 2 2 1 1  0 1 1
P44 3 30 0 24 3 1

 

1、T0时刻系统是否存在安全序列?

    Available(3,3,2)> Need1(1,2,2)【这里也可以是need3,只要比Available(3,3,2)小就行,答案不唯一】----> 可用资源分配给P1,直到P1进程执行完成,然后Available = Available(3,3,2)+ Allocation1(2,0,0) = (5,3,2)

    Available > Need3 -----> 可用资源分配给P3,直到P3进程执行完成,然后Available = Available + Allocation3 = (7,4,3)

    Available> Need4.....

    ..........

    得到安全序列为:P1,P3,P4,P2,P0

2、P1请求资源:P1发出请求向量Request(1,0,2),系统是否接受该请求?请使用银行家算法检查

    第一步(假分配检查):把Request分配给P1,必须满足Request要小于Available,Request要小于Need。

                       Request(1,0,2)< Available(3,3,2)

                       Request(1,0,2)< Need(1,2,2)

        因为满足第一步检查,进入第二层检查(安全序列检查)。

    第二步(安全序列检查):建立安全性检查表

    Work1=Available(3,3,2)-Request(1,0,2)=( 2,3,0 )

    Need1=Need1( 1,2,2 )-Request(1,0,2)=( 0,2,0 )

    Allocation1=Allocation1( 2,0,0 )+Request(1,0,2)=( 3,0,2 )


Work  NeedAllocation  Work+Allocation  Finish
P12 3 00 2 03 0 2

























  如果 Work > Need ,那么执行Work+Allocation,得到:                


Work  NeedAllocation  Work+Allocation  Finish
P1  2 3 00 2 0    3 0 2 5 3 2 true

5 3 2    





















   找到Need<Work的进程,如果没有找到这样的进程而进程集合没有执行,则算法返回,得到不存在安全序列结果,否则继续执行该算法。

   这里我们找到了P3进程。修改安全序列检查表:


Work  NeedAllocation  Work+Allocation  Finish
P1  2 3 00 2 0    3 0 2 5 3 2 true
P35 3 2    0 1 1  2 1 1 7 4 3 true

7 4 3















  这样一直执行到所有的进程到完成,以完成该安全序列检查表:


Work  NeedAllocation  Work+Allocation  Finish
P1  2 3 00 2 0    3 0 2 5 3 2 true
P35 3 2    0 1 12 1 1 7 4 3 true
P47 4 34 3 10 0 2 7 4 5 true
P07 4 57 4 30 1 0 7 5 5 true
P27 5 56 0 03 0 210 5 7 true

      这样就找到了整个安全序列为:P1,P3,P4,P0,P2


推荐您阅读更多有关于“”的文章

  • 0
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
5 银行家算法实现 5.1 实验类型 设计型(4学时)。 5.2 实验目的 1) 理解死锁避免相关内容; 2) 掌握银行家算法主要流程; 3) 掌握安全性检查流程。 5.3 实验描述 本实验主要对操作系统中的死锁预防部分的理论进行实验。要求实验者设计一个程序,该程序可对每一次资源申请采用银行家算法进行分配。 5.4 实验内容 1) 设计多个资源(≥3); 2) 设计多个进程(≥3); 3) 设计银行家算法相关的数据结构; 4) 动态进行资源申请、分配、安全性检测并给出分配结果。 5.5 实验要求 1) 编写程序完成实验内容; 2) 画出安全性检测函数流程图; 3) 撰写实验报告。 5.6 测试要求 1) 进行Request请求,输入参数为进程号、资源号和资源数; 2) 进行3次以上的Request请求; 3) 至少进行1次资源数目少于可用资源数,但不安全的请求。 5.7 相关知识 5.7.1 银行家算法的数据结构 1) 可利用资源向量Available。其中每个元素代表每类资源的数目。 2) 最大需求矩阵Max。其中每个元素代表每个进程对于每类资源的最大需求量。Max[i,j]=K表示i进程对于j类资源的最大需求量为K。 3) 分配矩阵Allocation。其中每个元素代表每个进程已得到的每类资源的数目。 4) 需求矩阵Need。其中每个元素代表每个进程还需要的每类资源的数目。 5.7.2 银行家算法 Request i [j]=K表示进程Pi需要K个j类资源。 1) 如果Request i [j]≤Need[i , j],便转向步骤2,否则认为出错。 2) 如果Request i [j]≤Available[j],便转向步骤3,否则表示无足够资源,Pi需等待; 3) 系统尝试分配资源给Pi; 4) 系统进行安全性检查,检查此次资源分配后,系统是否安全。如果安全,则正式分配资源,否则撤销此次分配。 5.7.3 安全性算法 1) 设置两个向量:工作向量Work和Finish。算法开始时Work=Available;Finish表示系统是否有足够的资源分配给进程,使之运行完成,开始时,令Finish[i]=False;如果有足够的资源分配给进程,则令Finish[i]=True。 2) 从进程集合中找到一个能满足下列条件的进程:Finish[i]=False;Need[i,j] ≤ Work[j],若找到,执行步骤3),否则,执行步骤4); 3) Pi获得所需资源后,可顺利执行指导完成,并释放它占有的资源。并执行: Work[j]=Work[j]+Allocation[i , j]; Finish[i] = True; 到第2)步。 4) 直到所有Finish[i]=True,表示系统处于安全状态;否则系统处于不安全状态。 5.8 实验设备 PC机1台,要求安装DOS7.1、Turbo C3.0、Windows2000。 5.9 实验成绩评定 实验成绩评定方式包含实验报告成绩、实验过程成绩两个部分,其中实验过程成绩占60%、实验报告成绩占40%,如果其中任何一个部分成绩不及格,则总成绩按不及格处理。 5.10 实验报告 按照实验目的、实验内容、实验要求、实验设备、测试等部分进行组织。 5.11 实验思考 1) 针对死锁有哪些可行方案? 2) 死锁解除的难点是什么?

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值