第3章 处理机调度与死锁

1,死锁

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

2,死锁与饥饿的区别

死锁(Deadlock): 指进程之间无休止地互相等待(堵塞状态)

饥饿(Starvation):指一个进程无休止地等待(运行状态)

3,产生死锁的原因

1)死锁发生:双方都拥有部分资源,同时在请求对方已占有的资源。

2)请求推进的次序与对非剥夺性资源的争用都是造成死锁的原因。 

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

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

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

4,产生死锁的必要条件

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

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

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

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

4)环路等待条件

5,处理死锁的基本方法

事先预防:

1)预防死锁 设置限制条件,破坏四个必要条件的一个或几个,预防发生死锁。 较易实现。限制条件的严格也会导致系统资源利用率和系统吞吐量降低。

2)避免死锁 不须事先限制,破坏四个必要条件,而是在资源的动态分配过程中,用某种方法去防止系统进入不安全状态,从而避免发生死锁。 这种事先加以较弱限制的方法,实现上有一定难度,但可获较高的资源利用率及系统吞吐量,目前在较完善的系统中,常用此方法来避免发生死锁。

事后处理:

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

4)解除死锁。 与死锁检测配套的一种措施。 常用的实施方法:撤销或挂起一些进程,以便回收一些资源并将他们分配给已阻塞进程,使之转为就绪以继续运行。 死锁的检测与解除措施,有可能使系统获得较好的资源利用率和吞吐量(死锁几率不一定很高),但在实现上难度也最大。

6,银行家算法避免死锁

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

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

利用安全性算法在下表找一个安全序列{P1,P3,P4,P2,P0},故是安全的。(最后检查应是资源释放完后又回到10、5、7 )

A,B,C现在资源数目依次是3,3,2,依次检查是否安全:P0不安全,P1安全,把资源给P1,P1完成后释放占用的所有资源,所以现在A,B,C的资源数目是5,3,2,,然后依次检查P2不安全,P3安全,P3完成后释放资源,A,B,C资源数目为7,4,3,P4安全,释放资源数目为7,4,5,检查P2安全,释放资源A,B,C资源数目为10,4,7,检查P0安全,释放资源A,B,C数目为10,5,7

7,死锁的检测

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

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

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

1),资源分配图

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

圆圈表示进程

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

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

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

2),死锁定理

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

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

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

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

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

8,死锁的解除

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

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

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

死锁处理方法比较

### 操作系统中进程调度安全状态判定 #### 安全状态定义 在操作系统理论中,当系统的当前资源分配状况能够找到至少一种顺序,在这种顺序下所有进程都能顺利完成执行,则认为此状态下系统处于安全状态。反之则称为不安全状态。 #### 银行家算法应用实例解析 针对给出的具体场景——即有五个进程(P0至P4),以及三种类型的资源(A, B, C): - **初始条件** - 可用资源数量分别为A=1,B=6,C=2,D=2。 | 进程 | 已分配资源 (Allocation)| 所需额外资源 (Need) | |---|---|---| | P0 | 0 0 3 2 | 0 0 1 2 | | P1 | 1 0 0 0 | 1 7 5 0 | | P2 | 1 3 5 4 | 2 3 5 6 | | P3 | 0 3 3 2 | 0 6 5 2 | | P4 | 0 0 1 4 | 0 6 5 6 | 通过构建工作向量Work并尝试寻找可能的工作路径来验证是否存在一个可行的安全序列[^2]。 经过计算得出结论:存在一条有效的安全序列<P0,P3,P4,P1,P2>,因此可以断言在这个配置条件下系统确实位于安全区域内。 #### 请求处理评估 假设现在收到来自P2的新请求(Request=[1,2,2,2]),为了决定是否应该批准这个新的资源申请,需要再次模拟整个过程,并考虑如果给予这些资源之后剩余可利用的数量是否会使得其他等待中的任一进程也无法继续运行下去而陷入僵局。 一旦按照上述假定进行了更新后的重新测试发现剩下的可用资源不足以支持任何未完成的任务进一步获取所需资源直至结束其生命周期的话,那么显然这样的决策将会把系统带入到危险境地;具体来说就是剩下(0,4,0,0)单位的闲置资源明显不足以为后续操作提供保障,所以应当拒绝此次请求以免造成潜在的风险。 ```python def banker_algorithm(allocation_matrix, max_demand_matrix, available_resources, request_vector=None): n_processes = len(allocation_matrix) work = list(available_resources) finish = [False] * n_processes while not all(finish): found_safe_process = False for i in range(n_processes): if not finish[i]: need_i = [] for j in range(len(max_demand_matrix[i])): need_i.append(max_demand_matrix[i][j]-allocation_matrix[i][j]) can_be_allocated = True for k in range(len(work)): if need_i[k]>work[k]: can_be_allocated=False if can_be_allocated and ((request_vector is None) or all([need_i[l]>=request_vector[l] for l in range(len(request_vector))])): # Add allocated resources back to the pool when process finishes. for m in range(len(work)): work[m]+=allocation_matrix[i][m] finish[i]=True found_safe_process=True if not found_safe_process: break return all(finish), work # Example usage with provided data points allocations = [[0,0,3,2],[1,0,0,0],[1,3,5,4],[0,3,3,2],[0,0,1,4]] max_demands=[[0,0,1,2], [1,7,5,0], [2,3,5,6], [0,6,5,2], [0,6,5,6]] avail_res=[1,6,2,2] req_vec_P2=[1,2,2,2] is_system_safe_before_request, _ = banker_algorithm(allocations,max_demands, avail_res) print("Is system safe before new resource allocation:", "Yes" if is_system_safe_before_request else "No") _, remaining_after_allocation_to_p2 = banker_algorithm( allocations, max_demands, [a-r for a,r in zip(avail_res, req_vec_P2)], req_vec=req_vec_P2 ) if any(x<0 for x in remaining_after_allocation_to_p2): print("System would enter unsafe state after allocating requested resources.") else: _, final_state_post_alloc = banker_algorithm( allocations, max_demands, [sum(pair)-r for pair,r in zip(zip(*allocations)[i]+tuple(req_vec_P2), tuple(req_vec_P2))] ) print("Final availability post-allocation:",final_state_post_alloc,"Safe?" ,all(final_state_post_alloc)) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值