操作系统 —— 8 死锁与进程间通信

1 死锁

1.1 死锁问题

日常生活中：

os中：

1.2 死锁模型

需求方：进程来表示
需求的资源：CPU、内存单元、IO资源、共享一个变量。。。可以有n个
每个进程使用资源如下：

• 空闲资源，可能申请得到可能申请不到
• 被使用状态，其他资源不可以使用这个资源了
• 空闲资源，当进程使用完这个资源后释放资源

P_i ->R_j ：进程需要资源
R_j ->P_i ：当前资源被进程使用


R₂ 的1个资源给P₁ ，另1个资源给P₂
R₁的唯一1个资源给了P₂ ，P₁ 想要R₁ 的资源但只能等待（sleep）
R₃ 的唯一1个资源给了P₃ ，P₂ 想要R₃ 的资源但只能等待（sleep）
由于过一段时间进程P₃ 用完资源后就会释放，所以不存在死锁情况

增加1条边后，P₃ 需要R₂ 的资源（形成了环）
死锁产生的典型特征：进程与所需的资源的链接关系形成了环


虽然也有环，但是不会产生死锁，因为一旦P₂ 或P₄ 释放了资源，P₁ 或P₃ 就会得到资源而去执行（假设P₁ 和P₃都只需要一个资源 ，如果他们需要多个资源，那么即使P₂ 或P₄ 释放了资源，他们也得不到满足）
所以死锁会有环，但有环不一定就会存在死锁

1.3 死锁特征

死锁的4个必要条件
出现死锁会出现上述4个
但出现上述4个不一定就出现死锁

右P2和P4持有但并不等待

1.4 死锁处理方法

为什么会有忽略这个死锁这个设计？
1、恢复死锁开销很大
2、设置一系列的约束让os不会进入死锁状态会使os的功能受到大大的限制，使得应用程序和os功能不能充分的去执行，所以靠假设来忽略死锁这个问题，这是经常采用的，开销较小

1.4.1 死锁预防（Deadlock Prevention）

出现死锁的4个条件，打破任意1个，只要是合理的打破，就会有死锁预防的效果

不保证访问资源的互斥，会产生执行的不确定性问题，不太好

一开始就把一个进程所需要的所有资源都占用，但是进程使用每个资源的间隔可能会很大，所以会导致系统的效率很低，可能会产生饥饿

互斥资源采用抢占就失去了意义，所以改成抢占也不行

给资源排序，只能序号递增或递减的申请资源，确保进程间形不成环。
嵌入式系统里用的多，因为嵌入式系统资源有限

死锁预防是要完全不发生死锁
死锁避免是死锁要发生时，让他不要发生

1.4.2 死锁避免（Deadlock Avoidance）

申请资源时进行判断是否会造成死锁，若可以造成死锁，则会给使用资源，需要系统具有一些额外的先验信息提供


如果分配资源后不会造成死锁，则是安全状态
分配资源后可能形成环，则是不安全状态
不安全状态包含死锁状态
进程按照一个序列先后执行是安全的的条件：假设轮到P_i 执行，则P₀ 到P_i-1使用的资源释放后和一直都未使用的资源能够满足P_i 的执行，按这个序列执行，所有进程都能正常的运行，不会死锁

不安全：出现环，因此不安全包含死锁

银行家算法

判断死锁太麻烦，所以改为判断是否是不安全的

安全状态检测算法：


银行家算法：
Request向量 ：每个进程需要的每种资源的个数

上图是否可以找到一个安全序列？
假设P1到P4四个进程都没有结束，看有没有1个执行序列让每个进程都正常结束
找一个进程的Need是否都小于Available向量0,1,1，P2满足，将finish[2]设为true，P2使用完资源后会释放掉，A中的P2的（6，1，2）会被累加到Available的V（0，1，1）上，变为：



所有找到1个安全序列：P2，P1，P3，P4

假设P1发出请求1，0，1，银行家算法是否会接收？
给P1分配1，0，1

分派完后会发现available的0,1,1不满足任何一个进程的Need，因此银行家算法不会满足P1发出的1,0,1的请求

1.4.3 死锁检测（Deadlock Detection）

条件放宽

• 死锁避免是没有死锁，一旦发现是不安全状态就不能继续申请资源
• 死锁检测是允许系统进入死锁状态，到某一阶段判断一下是否存在死锁，一旦发现有死锁，就启动恢复机制。把死锁的检测挪到系统运行中不再是每次发出请求时就判断
  
  
  
  定期执行这个算法去看系统里是否死锁
  开销较大，需要知道每个进程所需要的最大资源个数，所以不常使用
  
  P0->P2->P1->P3->P4
  
  
  检测出死锁后，就要考虑要把哪个进程kill掉，没有明确规定很难选出哪个进程，因此检测算法更多用在开发阶段

1.4.4 死锁恢复（Recovery from Deadlock）

kill哪个进程，方案如下（终止进程）：

资源抢占：

2 进程间通信（IPC）

2.1 概述

（a）：进程间间接通信
（b）：进程间直接通信

链路建立需要os的支持（os可以访问到所有的计算机资源，来建立这个通路），因为链路打破了进程间的隔离



阻塞：要发送一个消息，没法送完的话就把它阻塞，只有发送完后才回去接着干下面的事
非阻塞：要发送消息，成功与否不管，此操作会很快返回。成功和结束的时间可能和它本身send和return的时间会有很大的间距，这就是异步的体现

2.2 进程间通信方法

如果把消息采用缓存把它存起来，缓存最主要的是提高效率，来避免发送方和接收方之间的不匹配（可能发的很快收的很慢也可能收的很快发的很慢）临时把不能处理的发送方和接收方的信息存起来来提高效率

如果没有数据，接收方不得不等

信号（通知）

signal与硬件中断不同：硬件让CPU去处理一下，会产生一个硬件中断(interput)，signal是软件
os由于某种原因给应用程序发了信号，应用程序如何处理？

• catch：
• ingore：不进行处理
• mask：

很灵活，效率较高，信号只是一个很小的bite，起到通知的效果，不能传输数据。被处理完成后会直接回到中断的程序重新执行
os提供怎样的手段就可以完成上述的功能呢？

1. 应用程序针对某个单独的信号做处理，要在这个程序开始的时候注册一个针对某个信号的handles，把这个作为系统调用发给os，os就会知道当产生某个信号时，会调用应用程序编写的一个信号处理函数
2. 一旦产生了这个信号，os怎么能让当前运行的进程停下来，跳到信号处理函数去执行呢？当os收到这个信号时处于内核态，当它从内核态返回用户态去响应信号的哪个程序时要提前做好准备，返回去的哪个点要改成调用信号处理函数的入口，结合系统调用可知，他要把应用软件的堆栈进行修改，使得本来返回到系统调用的后一条语句变成信号处理函数的入口，同时把信号处理函数之后要执行的地址作为后面的一个返回地址。这样就会使从内核返回到应用程序执行的时候，他会根据留的栈信息跳到信号处理函数入口去执行，这时候回到了用户态，用户态的这个函数执行完毕后，会返回调它的函数，即被打断的地方，然后继续执行。一般的不会去修改用户程序的堆栈，木马会

管道（数据交换）

很早的机制，设计unix的专家希望把每一个小的程序实现一个单独的小功能，然后把它们灵活的组合起来实现一个复杂的功能。把一个程序的输出定向为另一个程序的输入

shell是一个进程，当这个进程收到ls | more后，他就知道这是2个命令结合在一起工作，然后创建2个进程——ls和more，然后他把ls的输出做特殊处理，把输出重定向到1个管道（相当于内存中的1个buffer），而不是屏幕，然后more进程从管道中取数据
管道是有限的，如果ls的输出到管道more来不及取会阻塞

消息队列（数据交换）

消息处理与管道

• 管道是父进程把子进程建立好的通道，如果进程间无父子关系，管道就无法工作了
• 管道里的数据是字节流，没有用结构化来表示
• 消息队列可以客服进程间无父子关系
• send\receive一个结构化数据，使得编写复杂程序更加灵活方便
  
  也会满或空

共享内存

每个进程都可以看到
直接读写内存完成数据共享

如何实现共享内存？
把同一块的物理内存映射到不同进程的相同或不同的地址空间上去