死锁

类型: 资源死锁, 通信死锁 etc

根据 拥有资源的进程抢占而不产生副作用

  • 可抢占资源 preemptable resource

  • 不可抢占资源 non

使用资源的顺序: 请求 -> 使用 -> 释放

1. 死锁定义

如果一个进程集合中的每个进程都在等待只能由该进程集合中的其他进程才能引发的时间, 那么, 该进程集合是死锁的

2. 死锁建模– 资源分配图

圆形表示进程, 方形表示资源, 进程 -> 资源 表示请求, 进程 <- 资源, 表示占有

资源分配图

3. 处理死锁

3.1. 鸵鸟算法

忽略该问题

3.2. 检测并恢复

检测死锁并恢复

3.2.1. 死锁检测

数据结构

死锁检测算法

3.2.2. 死锁恢复

3.2.2.1. 利用抢占

选择挂起某个进程, 取决于哪一个进程拥有比较容易收回的资源

3.2.2.2. 利用回滚

周期性地保存 检查点(checkpoint), 检查点应包括存储映像, 资源状态 (资源分给了哪些进程). 由于检查点不覆盖, 逐渐累积可能会占大量储存

3.2.2.3. 杀死进程

可以杀死环类的进程, 如果不行继续, 也可以杀死环外的进程 (以释放环类进程需要的资源), 杀死的进程应该满足: 重新运行不会带来副作用, 比如编译进程可以, 但是数据库更新进程不行

3.3. 死锁避免

在分配资源时避免发生死锁

3.3.1. 资源轨迹图

资源轨迹图

3.3.2. 安全区域与不安全区域

横坐标是 A 进程执行代码过程, 纵坐标是 B 进程执行代码的过程, 阴影部分需要使用相应资源. 在单 cpu 上, 虚线轨迹, 只能是向上或向右延伸. 阴影部分表明两个进程都使用了一个资源, 互斥规则决定不可能进入阴影区域. . 而在图中的虚线轨迹, 目前还有机会不形成死锁, 称为安全区域. 可以发现, 只要轨迹进入了 I5,I6,I1,I2, 围成的区域, 就一定会形成死锁, 这就是不安全区域

3.3.3. 银行家算法

Dijkstra 提出, banker’s algorithm
基本思路就是 每次满足一个进程的资源 请求前, 检测是否会造成死锁, 如果造成, 就不满足其请求, 否则满足.(死锁检测算法可以利用上文中的)

银行家算法

缺点: 很多进程在运行前是不知道其需要资源的最大值, 而且进程数不断变化, 原本的资源也可能突然间不可用 (如磁带机可能会坏掉), 所以缺乏实用价值 , 极少有系统使用

3.4. 死锁预防

3.4.1. 死锁条件

  • 互斥
  • 占有和请求
  • 不可抢占
  • 环路等待
    针对死锁条件, 由于是必要条件, 所以破坏其中一个就可以预防死锁的发生.

3.4.2. 破坏互斥条件

可以用虚拟技术使资源不被一个进程所独占, 如打印机的假脱机技术 (spooling),
还有一个思路: 避免分配那些不是绝对必要的资源, 尽量做到尽可能少的进程可以真正请求资源

3.4.3. 破坏占有和等待条件

一种实现方法: 规定所有进程在开始执行前请求所需的全部资源
缺点和银行家算法一样, 很多进程直到运行时才知道所需多少资源.
另一种方案是当一个进程请求资源时, 先释放其当前占有的所有资源

3.4.4. 破坏不可抢占条件

比如打印机假脱机技术, 但是不是所有资源都可以类似的虚拟化, 比如数据库的记录或者操作系统中的表都必须被锁定

3.4.5. 破坏环路等待条件

给资源编号, 进程只能按编号的顺序 (升序) 请求. 这样资源分配图不会出现环,.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值