2进程的基础

---

前言

次文章为观看王道考研课程(操作系统)的笔记
视频链接：https://www.bilibili.com/video/BV1YE411D7nH?spm_id_from=333.337.search-card.all.click

2.1进程

2.1.1 定义

$程序$：就是一个指令序列

早期的计算机(只支持$单道$程序)：
内存中存放该程序的程序段和数据段
(程序的代码放在程序段内，程序运行过程处理的数据放在数据段内(如变量))

引入$多道$程序技术之后：
系统为每个运行的程序配置了一个数据结构，称为进程控制块(PCB), 用来描述进程的各种信息(如程序代码块存放的位置)
为了方便操作系统管理，完各程序并发执行，引入了$进程、进程实体的概念$

PCB、程序段、数据段三部分构成了$进程实体(进程映像)$。一般情况下，我们把进程实体就简称为进程，例：所谓创建进程，实质上是创建进程实体中的PCB，而撤销进程，实质上是撤销进程实体中的PCB。
注意：$PCB是进程存在的唯一标识！$

从不同的角度，进程可以有不同的定义，比较传统典型的定义有(强调动态性)：

1. 进程是程序的一次$执行过程$。
2. 进程是一个程序及其数据在处理机上顺序执行时所$发生的活动$。
3. 进程是具有独立功能的程序在数据聚合上KaTeX parse error: Undefined control sequence: \colorblue at position 1: \̲c̲o̲l̲o̲r̲b̲l̲u̲e̲}运行的过程，它是系统进行资源分配和调度的一个独立单位

引入进程实体的概念后，可以把进程定义为：
$进程$是进程实体的$运行过程$，是系统进行$资源分配$和$调度$的一个独立单位

注：严格来说进程实体和进程并不一样，进程实体是静态的，进程是动态的。一般不做区分

2.1.2 组成

进程(进程实体)由$程序段、数据段、PCB$三部分组成
程序段：程序代码即存放在此
数据段：程序运行时使用、产生的运行数据。如全局变量、局部变量，宏定义的常量 就存放在数据段内
PCB：操作系统通过PCB来管理进程，因此PCB中应该包含操作系统对其进行管理所需要的各种信息

$PCB\{\begin{array}{l}进程描述信息\{\begin{array}{l}进程标识符PID当进程被创建时，操作系统会为该进程分配一个唯一的、不重复的ID、用来区分不同的进程（类似于身份证号）\\ 用户标识符UID\end{array}\\ 进程控制和管理信息\{\begin{array}{l}进程当前状态\\ 进程优先级\end{array}\\ 资源分配清单\{\begin{array}{l}程序段指针\\ 数据段指针\\ 键盘\\ 鼠标\end{array}\\ 处理机相关信息：各种寄存器值(当前进程切换时需要把进程当前的运行情况记录下来保留在PCB中，如程序计数器的值表示了当前程序执行到了那一句)\end{array}$

2.1.3 进程的组织方式

$进程的组织方式\{\begin{array}{l}链接方式\{\begin{array}{l}按照进程状态将PCB分为多个队列\\ 操作系统持有指向各个队列的指针\end{array}\\ 索引方式\{\begin{array}{l}根据进程状态的不同，建立几张索引表\\ 操作系统持有指向各个索引表的指针\end{array}\end{array}$

链接方式：

执行指针 —> $PCB2$
执行指针指向当前处于运行态(执行态)的进程，单个CPU计算机中，同一时刻只会有一个进程处于运行态

就绪队列指针 —> $PCB5$ —> $PCB1$ —> $PCB4$
就绪队列指针指向当前处于就绪状态的进程，通常会把优先级高的进程放在队头

阻塞状态指针 —> $PCB3$ —> $PCB7$ —> $PCB6$
指向当前处于阻塞状态的进程，很多操作系统还会根据阻塞原因不同再分为多个阻塞队列

索引方式：

执行指针 —> $PCB2$

就绪表指针 —> 就绪索引表 —> 表中每个元素指向一个就绪$PCB$

阻塞表指针 —> 阻塞索引表 —> 表中的每个元素指向一个阻塞$PCB$

2.1.4 特征

$进程的特征\{\begin{array}{l}动态性：进程是程序的一次执行过程，是动态地产生、变化和消亡的\\ 并发性：内存中有多个进程实体，各进程可并发执行\\ 独立性：进程是能够独立运行、独立获得资源，独立接受调度基本单位\\ 异步性：各进程按各自独立的、不可预知的速度向前推进，操作系统要提{供}^{\prime \prime }进程同步机{制}^{\prime \prime }来解决异步问题\\ 结构性：每个进程都会配置一个PCB，结构上看，进程由程序段，数据段，PCB组成\end{array}$

2.2 进程的状态与转换

2.2.1 状态

$三种基本状态\{\begin{array}{l}运行态(Running):占有CPU，并在CPU上运行\{\begin{array}{l}注意：单核处理机环境下，每一时刻最多只有一个进程处于运行态。\\ 双核环境下可以同时有两个进程处于运行态\end{array}\\ 就绪态(Ready):已经具备运行条件，但由于没有空闲CPU，而暂时不能运行\{\begin{array}{l}进程已经拥有了除处理机之外所有需要的资源，一旦获得处理机，\\ 即可立即进入运行态开始运行。\end{array}\\ 阻塞态(Waiting/Blocked,又称：等待态):因等待某一事件而暂时不能运行\{\begin{array}{l}如：等待操作系统分配打印机、等待读磁盘操作的结果。\\ CPU是计算机中最昂贵的部件，为了提高CPU的利用率，\\ 需要将其它进程需要的资源分配到位，才能得到CPU的服务\end{array}\end{array}$

$另外两种状态\{\begin{array}{l}创建态(New，又称：新建态)：进程正在被创建，操作系统分配资源，初始化PCB\\ 终止态(Terminated),又称：结束态：进程正在从操作系统中撤销，操作系统会回收进程拥有的资源、撤销PCB\end{array}$

2.2.2 进程状态之间的转换

$进程之间的转换\{\begin{array}{l}就绪态->运行态：进程被调度\\ 运行态->就绪态：时间片到，或CPU被其它优先级高的进程抢占\\ 运行态->阻塞态：等待系统资源分配，或等待某事件的发生(主动行为)\\ 阻塞态->就绪态：资源分配到位，等待事件发生(被动行为)\\ 创建态->就绪态：系统完成创建进程相关的工作\\ 运行态->终止态：进程运行结束，或运行过程中遇到不可修复的错误\end{array}$

2.3 进程控制

2.3.1 基本概念

进程控制的主要功能是对系统中所有进程实施有效的管理，它具有创建进程、撤销已有进程、实现进程状态转换等功能。
简化理解：进程控制就是要实现进程之间的状态转换

用$原语$实现进程控制。原语的$特点$是执行期间$不允许被中断$，只能一气呵成。
这种不可被中断的操作即$原子操作$。
原语采用”$关中断$指令“和”$开中断$指令“实现

… -> $关中断$指令 -> 原语代码1 -> 原语代码2 … -> $开中断$指令 -> 代码3 -> 代码4…
在两种中断指令之间的原语执行过程是不能被$外部中断信号$打断的

显然，$关/开中断指令$的权限非常大，必然是只允许在$核心态$下执行的$特权指令$

2.3.2 进程控制相关原语

进程控制会导致进程状态的转换。无论哪个原语，要做的无非三类事情：

1. 更新PCB中的信息(如修改进程状态标志、将运行环境保存到PCB、从PCB恢复运行环境)
   a. 所有的进程控制原语一定都会修改进程状态标志
   b.剥夺当前运行进程的CPU使用权必然需要保存其运行环境
   c.某进程开始运行前必然要恢复运行环境
2. 将PCB插入合适的队列
3. 分配/回收资源

$进程的创建\{\begin{array}{l}创建原语\{\begin{array}{l}申请空白PCB\\ 为新进程分配所需要的资源\\ 初始化PCB\\ 将PCB插入就绪队列\end{array}\\ 引起进程创建的事件\{\begin{array}{l}用户登录：分时系统中，用户登入成功，系统会建立一个新的进程\\ 作业调度：多道批处理系统中，有新的作业放入内存时，会为其建立一个新的进程\\ 提供服务：用户向操作系统提出某些请求时，会创建一个进程处理该请求\\ 应用请求：由用户进程主动请求创建一个子进程\end{array}\end{array}$

创建原语：无->创建态->就绪 态

$进程的终止\{\begin{array}{l}撤销原语\{\begin{array}{l}从PCB集合中找到终止进程的PCB\\ 若进程正在运行，立即剥夺CPU，将CPU分配给其它进程\\ 终止所有子进程\\ 将该进程所有资源归还给父进程或操作系统\\ 删除PCB\end{array}\\ 引起进程终止的事件\{\begin{array}{l}正常结束\\ 异常结束\\ 外界干预\end{array}\end{array}$
撤销原语：就绪态/阻塞态/运行态 ->终止态->无

$进程的阻塞和唤醒\{\begin{array}{l}进程的阻塞\{\begin{array}{l}阻塞原语\{\begin{array}{l}找到要阻塞的进程对应的PCB\\ 保护进程运行现场，将PCB动态信息设置{为}^{\prime \prime }阻塞{态}^{\prime \prime }，暂时暂停进程运行\\ 将PCB插入相应事件的等待队列\end{array}\\ 引起进程阻塞的事件\{\begin{array}{l}需要等待系统分配某种资源\\ 需要等待相互合作的其它进程完成工作\end{array}\end{array}\\ 进程的唤醒\{\begin{array}{l}唤醒原语\{\begin{array}{l}在事件等待队列中找到PCB\\ 将PCB从等待队列移除，设置进程为就绪态\\ 将PCB插入就绪队列，等待被调度\end{array}\\ 引起进程唤醒的事件：等待事件发生\end{array}\end{array}$
阻塞原语和唤醒原语必须成对使用
阻塞原语：运行态->阻塞态
唤醒原语：阻塞态->就绪态

引起进程唤醒的事件：因何事阻塞，就应由何事唤醒

进 程 的 切 换 { 切 换 原 语 { 将 运 行 环 境 信 息 存 入 P C B P C B 移 入 相 应 队 列 选 择 另 一 个 进 程 执 行 ， 并 更 新 其 P C B 根 据 P C B 恢 复 新 进 程 的 运 行 环 境 引 起 进 程 切 换 的 原 因 { { 当 前 进 程 时 间 片 到 有 更 高 优 先 级 的 进 程 到 达 当 前 进 程 主 动 阻 塞 当 前 进 程 终 止 进程的切换\begin{cases}切换原语\begin{cases}将运行环境信息存入PCB\\PCB移入相应队列\\选择另一个进程执行，并更新其PCB\\根据PCB恢复新进程的运行环境\end{cases}\\引起进程切换的原因\begin{cases}\begin{cases}\end{cases}当前进程时间片到\\有更高优先级的进程到达\\当前进程主动阻塞\\当前进程终止\end{cases}\end{cases} 进程的切换⎩⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎧​切换原语⎩⎪⎪⎪⎨⎪⎪⎪⎧​将运行环境信息存入PCBPCB移入相应队列选择另一个进程执行，并更新其PCB根据PCB恢复新进程的运行环境​引起进程切换的原因⎩⎪⎪⎪⎨⎪⎪⎪⎧​{当前进程时间片到有更高优先级的进程到达当前进程主动阻塞当前进程终止​​
切换原语：运行态 -> 阻塞态/就绪态 就绪态->运行态

2.4 进程通信

进程通信就是指进程之间的信息交换
$各进程$拥有的$内存地址相互独立$
为了保证安全，$一个进程不能直接访问令一个进程的地址空间$

2.4.1 共享存储

两进程在内存中在共享空间进行通信

两个进程对共享空间的$访问$必须是$互斥$的（互斥访问通过操作系统提供的工具来实现）
操作系统只负责提供共享空间和同步互斥工具(如P、V操作)

共享存储：

• $基于数据结构$：比如共享空间里只能放一个长度为10的数组。这种共享的方式速度慢、限制多，是一种$低级通信$方式
• $基于存储区$：在内存中画出一块共享存储区，数据的形式、存放位置都是由进程控制而不是操作系统。相比之下，这种共享方式速度更快，是一种$高级通信$方式

2.4.2 消息传递

进程间的数据交换以$格式化的消息$（Message）为单位。进程通过操作系统提供的“发送消息/接收消息”两个$原语$进行数据交换。
消息：

• 消息头：消息头包括:发送进程ID、接受进程ID、消息类型、消息长度等格式化的信息
• 消息体

消息传递方式：

• 直接通信方式：消息直接挂到接收进程的消息缓冲队列上
• 间接通信方式：消息要先发送到中间实体（信箱)中，因此也称“信箱通信方式”。

2.4.3 管道通信

“管道”是指用于连接读写进程的一个共享文件，又名pipe文件。其实就是在内存中开辟一个大小固定的缓冲区

进程1 ----写数据----> 管道 ----读数据—> 进程2

1. 管道只能采用$半双工通信$，某一时间段内只能实现单向的传输。如果要实现$双向同时通信$，则$需要设置两个管道$。
2. 各进程要$互斥$地访问管道
3. 数据以字符流的形式写入管道，当$管道写满$时，$写进程$的write()系统调用将被$阻塞$，等待读进程将数据取走。当读进程将数据全部取走后，$管道变空$，此时$读进程$的read()系统调用将被$阻塞$。
4. 如果$没写满，就不允许读$。如果$没读空，就不允许写$。
5. 数据一旦被读出，就从管道中被抛弃，这就意味着$读进程最多只能有一个$，否则可能会有读错数据的情况。

2.5 线程、多线程模型

2.5.1 什么是线程，为什么要引入线程

有的进程可能需要“同时”做很多事，而传统的进程只能串行地执行一系列程序。为此，引入了“线程”，来增加并发度。
引入线程后,线程成为了程序执行流的最小单位。

1. 可以把线程理解为“轻量级进程”。
2. $线程$是一个$基本的CPU执行单元$，也是$程序执行流的最小单位$。
   引入线程之后，不仅是进程之间可以并发，进程内的$各线程之间$也可以$并发$，从而进一步$提升了系统的并发度$，使得一个进程内也可以并发处理各种任务（如$QQ$视频、文字聊天、传文件)
3. 引入线程后，$进程$只作为$除CPU之外的系统资源的分配单元$（如打印机、内存地址空间等都是分配给进程的）。

2.5.2 引入线程机制后，有什么变化

$带来的变化\{\begin{array}{l}资源分配、调度\{\begin{array}{l}传统进程机制中，进程是资源分配、调度的基本单位\\ 引入线程后，进程是资源分配的基本单位，线程是调度的基本单位\end{array}\\ 并发性\{\begin{array}{l}传统进程机制中，只能进程之间并发\\ 引入线程后，各线程之间也能并发，提高了并发性\end{array}\\ 系统开销\{\begin{array}{l}传统的进程间并发，需要切换进程的运行环境，系统开销大\\ 进程间并发，如果是同一进程切换，则不需要切换进程环境，系统开销小\\ 引入线程后，并发所带来的系统开销减小\end{array}\end{array}$

2.5 .3 线程有哪些重要属性

$线程的属性\{\begin{array}{l}线程是处理机调度的单位\\ 多CPU计算机中，各线程可占用不同的CPU\\ 每个线程都有一个线程ID,线程控制块(TCB)\\ 线程也有就绪、阻塞、运行三种基本状态\\ 现场几乎不拥有系统资源\\ 统一进程的不同线程共享进程资源\\ 由于共享内存地址空间，统一进程中的线程间通信甚至无需系统干预\\ 同一进程中的线程切换，不会引起进程的切换\\ 不同进程中的线程切换，会引起进程的切换\\ 切换进程中的线程，系统开销小\\ 切换进程，系统开销大\end{array}$

2.5.4 线程地实现方式

用户级线程

1. 用户级线程由应用程序通过线程库实现。
2. 所有的$线程管理工作$都由$应用程序负责$（包括线程切换）
3. 用户级线程中，$线程切换$可以在$用户态下即可完成$，无需操作系统干预。
4. 在用户看来，是有多个线程。但是在操作系统内核看来，并意识不到线程的存在。（用户级线程对用户不透明，对操作系统透明)
5. 可以这样理解，“$用户级线程$”就是“$从用户视角看能看到的线程$”

内核级线程

1. 内核级$线程的管理工作$由$操作系统内核$完成。线程调度、切换等工作都由内核负责，因此$内核级线程的切换$必然需要在 \color{red} 下才能完成。
2. 可以这样理解，“$内核级线程$”就是“$从操作系统内核视角看能看到的线程$”

在同时支持用户级线程和内核级线程的系统中，可采用二者组合的方式:将n个用户级线程映射到m个内核级线程上( n >= m)
$重点重点重点:$
操作系统只“看得见”内核级线程，因此只有$内核级线程才是处理机分配的单位$。

2.5.5 多线程模型

多对一模型

1. 多对一模型:多个用户及线程映射到一个内核级线程。每个用户进程只对应一个内核级线程。
2. 优点:用户级线程的切换在用户空间即可完成，不需要切换到核心态，线程管理的系统开销小，效率高
3. 缺点:当一个用户级线程被阻塞后，整个进程都会被阻塞，并发度不高。多个线程不可在多核处理机上并行运行

一对一模型

1. 一对一模型:一个用户及线程映射到一个内核级线程。每个用户进程有与用户级线程同数量的内核级线程。
2. 优点:当一个线程被阻塞后，别的线程还可以继续执行，并发能力强。多线程可在多核处理机上并行执行。
3. 缺点:一个用户进程会占用多个内核级线程线程切换由操作系统内核完成，需要切换到核心态，因此线程管理的成本高，开销大。

多对多模型

1. 多对多模型: n用户及线程映射到m个内核级线程$(n>=m)$。每个用户进程对应m个内核级线程。
2. 克服了多对一模型并发度不高的缺点，又克服了一对一模型中一个用户进程占用太多内核级线程，开销太大的缺点。

2.6 处理机调度概念、层次

2.6.1 基本概念

• 当有一堆任务要处理，但由于资源有限，这些事情没法同时处理。这就需要确定$某种规则$来$决定$处理这些任务的$顺序$，这就是“调度”研究的问题。
• 在多道程序系统中，进程的数量往往是多于处理机的个数的，这样不可能同时并行地处理各个进程。$处理机调度$，就是从就绪队列中$按照一定的算法选择一个进程$并$将处理机分配给它$运行，以实现进程的并发执行。

2.6.2 三个层次

高级调度(作业调度)

1. 由于内存空间有限，有时无法将用户提交的作业全部放入内存，因此就需要确定某种规则来决定将作业调入内存的顺序。
2. $高级调度（作业调度）$。按一定的原则从外存上处于后备队列的作业中挑选一个(或多个）作业,给他们分配内存等必要资源，并$建立相应的进程（建立PCB）$，以使它（们）获$得竞争处理机的权利。$
3. 高级调度是辅存（外存）与内存之间的调度。每个作业只调入一次，调出一次。$作业调入时会建立相应的PCB$，$作业调出时才撤销PCB$。高级调度主要是指调入的问题，因为只有调入的时机需要操作系统来确定，但调出的时机必然是作业运行结束才调出。

中级调度(内存调度)

1. 引入了虚拟存储技术之后，可将暂时不能运行的进程调至外存等待。等它重新具备了运行条件且内存又稍有空闲时，再重新调入内存。
2. 这么做的目的是为了$提高内存利用率$和$系统吞吐量$。
3. 暂时调到外存等待的进程状态为$挂起状态$。值得注意的是，$PCB$并不会一起调到外存，而是会$常驻内存$。PCB中会记录进程数据在外存中的存放位置，进程状态等信息，操作系统通过内存中的PCB来保持对各个进程的监控、管理。被挂起的进程PCB会被放到的$挂起队列$中。
4. $中级调度（内存调度）$，就是要决定将哪个处于挂起状态的进程重新调入内存。
5. 一个进程可能会被多次调出、调入内存，因此$中级调度$发生的$频率$要比高级调度$更高$。

低级调度(进程调度)

1. $低级调度（进程调度）$，其主要任务是按照某种方法和策略从就绪队列中选取一个进程，将处理机分配给它。
2. 进程调度是操作系统中$最基本的一种调度$，在一般的操作系统中都必须配置进程调度。进程调度的$频率很高$，一般几十毫秒一次。

2.6.3 三个层次的联系、对比

$\begin{array}{clccc}& 要做什么& 发生时间& 发生频率& 对进程状态的影响\\ 高级调度& & & & \\ (作业调度)& 按照某种规则，从后备队列& & & \\ & 中选择合适的作业将其调入内存,并为其创建进程& 外存->内存(面向作业)& 最低& 无->创建态->就绪态\\ 中级调度& & & & \\ (内存调度)& 按照某种规则，从挂起队列& & & \\ & 中选择合适的进程将其数据调回内存& 外存->内存(面向作业)& 中等& 挂起态->活动态\\ 低级调度& & & & \\ (进程调度)& 按照某种规则，从就绪队列& & & \\ & 中选择一个进程为其分配处理机& 内存->CPU& 最高& 就绪态->运行态\end{array}$

2.6.4 补充知识

进程的“挂起态”
七状态模拟

暂时调到外存等待的进程状态为$挂起状态(挂起态，suspend）$
挂起态又可以进一步细分为$静止就绪、静止阻塞$两种状态
五状态模型→七状态模型

1. 挂起状态 -> 活动状态：中级调度
2. 活动状态 -> 挂起状态：挂起
3. 静止阻塞 -> 静止就绪：事件出现
4. 创建 -> 静止就绪：内存不足

注意“挂起”和“阻塞”的区别，两种状态都是暂时不能获得CPU的服务，但挂起态是将进程映像调到外存去了，而阻塞态下进程映像还在内存中。
有的操作系统会把就绪挂起、阻塞挂起分为两个挂起队列，甚至会根据阻塞原因不同再把阻塞挂起进程进一步细分为多个队列。

2.7 进程调度的时机

2.7.1 时机

什么时候需要进程调度

• 当前运行的进$主动放弃$处理机
  1. 进程正常终止
  2. 运行过程中发生异常而终止
  3. 进程主动请求阻塞（如等待I/O)
• 当前运行的进$被动放弃$处理机
  1. 分给进程的时间片用完
  2. 有更紧急的事需要处理（如I/o中断)
  3. 有更高优先级的进程进入就绪队列

什么时候不能进程调度

1. 在$处理中断的过程中$。中断处理过程复杂，与硬件密切相关，很难做到在中断处理过程中进行进程切换。
2. 进程在$操作系统内核程序临界区$中。
3. 在$原子操作过程中$（原语）。原子操作不可中断，要一气呵成（如之前讲过的修改PCB中进程状态标志，并把PCB放到相应队列)

2.7.2 切换与过程

“侠义的调度”与“切换”的区别

$狭义的进程调度$指的是从就绪队列中$选中一个要运行的进程$。(这个进程可以是刚刚被暂停执行的进程，也可能是$另一个进程$，后一种情况就需要$进程切换$)
$进程切换$是指一个进程让出处理机，由另一个进程占用处理机的过程。

$广义的进程调度$包含了选择一个进程和进程切换两个步骤。

进程切换的过程需要做什么

1. 对原来运行进程各种数据的保存

2. 对新的进程各种数据的恢复
   (如:程序计数器、程序状态字、各种数据寄存器等处理机现场信息，这些信息一般保存在进程控制块)

注意:$进程切换是有代价的$，因此如果$过于频繁$的进行进程$调度、切换$，必然会使整个$系统的效率降低$，使系统大部分时间都花在了进程切换上，而真正用于执行进程的时间减少。

2.7.3 方式

非剥夺式调度方式(非抢占式)

$非剥夺调度方式$，又称$非抢占方式$。即，只允许进程主动放弃处理机。在运行过程中即便有更紧迫的任务到达，当前进程依然会继续使用处理机，直到该进程终止或主动要求进入阻塞态。

实现简单,系统开销小但是无法及时处理紧急任务，适合于早期的批处理系统

剥夺式调度方式(抢占式)

$剥夺调度方式$，又称$抢占方式$。当一个进程正在处理机上执行时，如果有一个更重要或更紧迫的进程需要使用处理机，则立即暂停正在执行的进程，将处理机分配给更重要紧迫的那个进程。

可以优先处理更紧急的进程，也可实现让各进程按时间片轮流执行的功能（通过时钟中断）。适合于分时操作系统、实时操作系统

2.8 调度算法的评价指标

2.8. 1 CPU利用率

由于早期的CPU造价极其昂贵，因此人们会$希望让CPU尽可能多地工作$
$CPU利用率$:指CPU“忙碌”的时间占总时间的比例。

$利用率=\frac{忙碌时间}{总时间}$

2.8. 2 系统吞吐量

对于计算机来说，希望能用尽可能少的时间处理完尽可能多的作业
$系统吞吐量$:单位时间内完成作业的数量

$系统吞吐量=\frac{总共完成了多少道作业}{总共花费了多少时间}$

2.8 .3 周转时间

周转时间、平均周转时间

对于计算机的用户来说，他很关心自己的作业从提交到完成花了多少时间。
$周转时间$，是指从$作业被提交给系统开始$，到$作业完成为止$的这段时间间隔。
它包括四个部分:作业在外存后备队列上等待作业调度（高级调度）的时间、进程在就绪队列上等待进程调度（低级调度）的时间、进程在CPU上执行的时间、进程等待I/O操作完成的时间。后三项在一个作业的整个处理过程中，可能发生多次。

（作业）周转时间 = 作业完成时间 - 作业提交时间

$平均周转时间=\frac{各作业周转时间之和}{作业数}$

带权周转时间、平均带权周转时间

$带权周转时间=\frac{作业周转时间}{作业实际运行的时间}$
带权周转时间必然$\geq$1
带权周转时间与周转时间一样，都是越小越好

$平均带权周转时间=\frac{各作业带权周转时间之和}{作业数}$

对于周转时间相同的两个作业，实际运行时间长的作业在相同时间内被服务的时间更多，带权周转时间更小，用户满意度更高。
对于实际运行时间相同的两个作业，周转时间短的带权周转时间更小,用户满意度更高。

2.8.4 等待时间

计算机的用户希望自己的作业尽可能少的等待处理机
$等待时间$，指进程/作业$处于等待处理机状态时间之和$，等待时间越长，用户满意度越低。

对于$进程$来说，等待时间就是指进程建立后$等待被服务的时间之和$，在等待I/O完成的期间其实进程也是在被服务的，所以不计入等待时间。
对于$作业$来说，不仅要考虑$建立进程后的等待时间，还要加上作业在外存后备队列中等待的时间。$

一个作业总共需要被CPU服务多久，被l/o设备服务多久一般是确定不变的，因此调度算法其实只会影响作业/进程的等待时间。当然，与前面指标类似，也有“$平均等待时间$”来评价整体性能。

2.8.5 响应时间

对于计算机用户来说，会希望自己的提交的请求（比如通过键盘输入了一个调试命令）尽早地开始被系统服务、回应。
$响应时间$，指从用户$提交请求$到$首次产生响应$所用的时间。

2.9 调度算法

2.9.1 先来先服务$(FCFS)$

算法思想：
主要从“公平”的角度考虑（类似于我们生活中排队买东西的例子）

算法规则
按照作业/进程到达的先后顺序进行服务

用于作业/进程调度
用于作业调度时，考虑的是哪个作业先到达后备队列;用于进程调度时，考虑的是哪个进程先到达 就绪队列

是否可抢占?
非抢占式的算法

优缺点
优点:公平、算法实现简单
缺点:排在长作业(进程）后面的短作业需要等待很长时间，带权周转时间很大，对短作业来说用户体验不好。即，某进程/作业长期 $FCFS$算法$对长作业有利，对短作业不利$

是否会导致饥饿
不会

2.9.2 短作业优先$(SJF)$

算法思想：
追求最少的平均等待时间，最少的平均周转时间、最少的平均平均带权周转时间

算法规则:
最短的作业/进程优先得到服务（所谓“最短”，是指要求服务时间最短)

用于作业/进程调度:
即可用于作业调度，也可用于进程调度。用于进程调度时称为“短进程优先(SPF,Shortest Process First）算法”

是否可抢占?:
$SJF和SPF$是$非抢占式$的算法。但是$也有抢占式的版本――最短剩余时间优先算法$$(SRTNN,ShortestRemainingTimeNext)$

优缺点:
优点:“最短的”平均等待时间、平均周转时间
缺点:不公平。$对短作业有利，对长作业不利$。可能产生$饥饿现象$。另外，作业/进程的运行时间是由用户提供的，并不一定真实，不一定能做到真正的短作业优先

是否会导致饥饿:
会。如果源源不断地有短作业/进程到来，可能使长作业/进程长时间得不到服务，产生“$饥饿$”现象。如果一直得不到服务，则称为“$饿死$”

注意细节：

1. 如果题目中$未特别说明$，所提到的“短作业/进程优先算法”$默认$是$非抢占式$的
2. 很多书上都会说“$SJF$调度算法的平均等待时间、平均周转时间最少”
   严格来说，这个表述是错误的，不严谨的。
   应该加上一个条件“在$所有进程同时可运行$时，采用$SIF$调度算法的平均等待时间、平均周转时间最少”;
   或者说“在$所有进程都几乎同时到达$时，采用$SJF$调度算法的平均等待时间、平均周转时间最少”;
   如果不加上述前提条件，则应该说“$抢占式$的短作业/进程优先调度算法（$最短剩余时间优先,SRNT$算法）的平均等待时间、平均周转时间最少”
3. 虽然严格来说，$SJF$的平均等待时间、平均周转时间并不一定最少，但相比于其他算法（如 $FCFS$),$SJF$依然可以获得较少的平均等待时间、平均周转时间
4. 如果选择题中遇到“$SJF$算法的平均等待时间、平均周转时间最少”的选项，那最好判断其他选项是不是有很明显的错误，如果没有更合适的选项，那也应该选择该选项

2.9.3 高响应比优先$(HRRN)$

算法思想：
要综合考虑作业/进程的等待时间和要求服务的时间

算法规则:
在每次调度时先计算各个作业/进程的$响应比$，选择$响应比最高的$作业/进程为其服务
$响应比=\frac{等待时间+要求服务时间}{要求服务时间}$

用于作业/进程调度:
即可用于作业调度，也可用于进程调度

是否可抢占?:
非抢占式的算法。因此只有当前运行的作业/进程主动放弃处理机时，才需要调度，才需要计算响应比

优缺点:
综合考虑了等待时间和运行时间（要求服务时间)
等待时间相同时，要求服务时间短的优先($SJF$的优点)
要求服务时间相同时，等待时间长的优先（$FCFS$的优点)
对于长作业来说，随着等待时间越来越久，其响应比也会越来越大，从而避免了长作业饥饿的问题

是否会导致饥饿:
不会

2.9.4 时间片轮转算法(RR)

算法思想：
公平地、轮流地为各个进程服务，让每个进程在一定时间间隔内都可以得到响应

算法规则:
按照各进程到达就绪队列的顺序，轮流让各个进程执行一个$时间片$（如$100ms$)。若进程未在一个时间片内执行完，则剥夺处理机，将进程重新放到就绪队列队尾重新排队。

用于作业/进程调度:
用于进程调度
（只有作业放入内存建立了相应的进程后，才能被分配处理机时间片)

是否可抢占?:
若进程未能在时间片内运行完，将被强行剥夺处理机使用权，因此时间片轮转调度算法属于$抢占式$的算法。由时钟装置发出$时钟中断$来通知CPU时间片己到

优缺点:
优点:公平;响应快，适用于分时操作系统;
缺点:由于高频率的进程切换，因此有一定开销;不区分任务的紧急程度。

是否会导致饥饿:
不会

2.9.5 优先级调度算法

算法思想：
随着计算机的发展，特别是实时操作系统的出现，越来越多的应用场景需要根据任务的紧急程度来决定处理顺序

算法规则:
调度时选择优先级最高的作业/进程

用于作业/进程调度:
既可用于作业调度，也可用于进程调度。甚至，还会用于在之后会学习的I/o调度中

是否可抢占?:
抢占式、非抢占式都有。做题时的区别在于:非抢占式只需在进程主动放弃处理机时进行调度即可，而抢占式还需在就绪队列变化时，检查是否会发生抢占。

优缺点:
优点:用优先级区分紧急程度、重要程度，适用于实时操作系统。可灵活地调整对各种作业/进程的偏好程度。
缺点:若源源不断地有高优先级进程到来，则可能导致饥饿

是否会导致饥饿:
会

2.9.6 多级反馈队列算法

算法思想：
对其他调度算法的折中权衡

算法规则:

1. 设置多级就绪队列，各级队列优先级从高到低，时间片从小到大
2. 新进程到达时先进入第1级队列，按$FCFS$原则排队等待被分配时间片，若用完时间片进程还未结束，则进程进入下一级队列队尾。如果此时已经是在最下级的队列，则重新放回该队列队尾
3. 只有第k级队列为空时，才会为k+1级队头的进程分配时间片

用于作业/进程调度:
用于进程调度

是否可抢占?:
$抢占式$的算法。在k级队列的进程运行过程中，若更上级的队列(1~k-1级）中进入了一个新进程，则由于新进程处于优先级更高的队列中，因此新进程会抢占处理机，原来运行的进程放回k级队列队尾。

优缺点:
对各类型进程相对公平($FCFS$的优点)﹔每个新到达的进程都可以很快就得到响应（RR的优点）;短进程只用较少的时间就可完成(SPF的优点）;不必实现估计进程的运行时间（避免用户作假);可灵活地调整对各类进程的偏好程度，比如CPU密集型进程、I/o密集型进程（拓展:可以将因l/o而阻塞的进程重新放回原队列，这样1/o型进程就可以保持较高优先级)

是否会导致饥饿:
会

注:比起早期的批处理操作系统来说，由于计算机造价大幅降低，因此之后出现的交互式操作系统〈包括分时操作系统、实时操作系统等）更注重系统的响应时间、公平性、平衡性等指标。而这几种算法恰好也能较好地满足交互式系统的需求。因此后三种算法适合用于交互式系统。(比如$UNIX$使用的就是多级反馈队列调度算法)

2.10 进程同步和互斥

2.10.1 什么是进程同步

$同步$亦称$直接制约关系$，它是指为完成某种任务而建立的两个或多个进程，这些进程因为需要在某些位置上$协调$它们的$工作次序$而产生的制约关系。进程间的直接制约关系就是源于它们之间的相互合作。

2.10.2 什么是进程互斥

我们把$一个时间段内只允许一个进程使用$的资源称为$临界资源$。许多物理设备（比如摄像头、打印机）都属于临界资源。此外还有许多变量、数据、内存缓冲区等都属于临界资源。
对临界资源的访问，必须$互斥$地进行。互斥，亦称$间接制约关系。进程互斥$指当一个进程访问某临界资源时，另一个想要访问该临界资源的进程必须等待。当前访问临界资源的进程访问结束，释放该资源之后，另一个进程才能去访问临界资源。

对临界资源的互斥访问，可以在逻辑上分为如下四个部分:

do {
    entry section;    //进入区
    critical section; //临界区
    exit section;     //退出区
    remainder section;//剩余区
} while(true)

进入区：负责检查是否可进入临界区,若可进入，则应设置正在访问临界资源的标志(可理解为“上锁”)，以阻止其他进程同时进入临界区
临界区：访问临界资源的那段代码
退出区：负责解除正在访问临界资源的标志（可理解为“解锁”）
剩余区：做其他处理

注意:
$临界区$是进程中$访问临界资源$的代码段。$进入区$和$退出区$是$负责实现互斥$的代码段。临界区也可称为“临界段”。

为了实现对临界资源的互斥访问，同时保证系统整体性能，需要遵循以下$原则$:

1. 空闲让进。临界区空闲时，可以允许一个请求进入临界区的进程立即进入临界区;
2. 忙则等待。当已有进程进入临界区时，其他试图进入临界区的进程必须等待;
3. 有限等待。对请求访问的进程，应保证能在有限时间内进入临界区（保证不会饥饿);
4. 让权等待。当进程不能进入临界区时，应立即释放处理机，防止进程忙等待。

2.11 进程互斥的软件实现方法

2.11.1 单标志法

算法思想:
两个进程在$访问完临界区后$会把使用临界区的权限转交给另一个进程。也就是说$每个进程进入临界区的权限只能被另一个进程赋予$

int trun = 0; //true 表示当前允许进入临界区的进程号
//p0 进程：
while (true != 0); //①进入区
critical section;  //②临界区
trun = 1;          //③退出区
remainder section; //④剩余区
//P1进程
while (true != 1); //⑤进入区
critical section;  //⑥临界区
trun = 0;          //⑦退出区
remainder section; //⑧剩余区

$turn$的初值为0，即刚开始只允许О号进程进入临界区。
若$P1$先上处理机运行，则会一直卡在⑤。直到$P1$的时间片用完，发生调度，切换$P0$上处理机运行。代码①不会卡住$P0$，$P0$可以正常访问临界区，在$P0$访问临界区期间即时切换回$P1$，$P1$依然会卡在⑤。只有$P0$在退出区将turn改为1后，$P1$才能进入临界区。

因此，$该算法可以实{现}^{\prime \prime }同一时刻最多只允许一个进程访问临界{区}^{\prime \prime }$

$turn$表示当前允许进入临界区的进程号，而只有当前允许进入临界区的进程在访问了临界区之后，才会修改turn的值。也就是说，对于临界区的访问，一定是按$PO\to P1\to PO\to P1\to .....$.这样轮流访问。这种必须“轮流访问”带来的问题是，如果此时允许进入临界区的进程是PO，而PO一直不访问临界区，那么虽然此时临界区空闲，但是并不允许$P1$访问。
因此，$单标志法$存在的$主要问题$是:$违背“空闲让进”原则$。

2.11.2 双标志先检查

算法思想:
设置一个布尔型数组$flag[]$，数组中各个元素用来$标记各进程想进入临界区的意愿$，比如${}^{\prime }flag[0]=tur{e}^{\prime }$意味着0号进程PO现在想要进入临界区。每个进程在进入临界区之前先检查当前有没有别的进程想进入临界区，如果没有，则把自身对应的标志flag[i]设为true，之后开始访问临界区。

bool flag[2]; //表示进入临界区意愿的数组
flag[0] = false;
flag[1] = false;//刚开始设置为两个进程都不想进入临界区
//p0进程
while (flag[1]);//1
flag[0] = true;//2
critical section;//3
flag[0] = false;//4
remainder section;
//p1进程
while (flag[0]);//5 如果此时P0想要进入临界区，P1就会一直等待
flag[1] = true;//6 标记为P1进程想要进入临界区
critical section;//7 访问临界区
flag[1] = false;//8 访问完临界区，修改标记为P1不想要使用临界区
remainder section;

若按照$①⑤②⑥③⑦....$的顺序执行，$PO和P1$将会同时访问临界区。
因此，双标志先检查法的$主要问题$是:$违反“忙则等待”原则。$
原因在于，$进入区$的“检查”和“上锁”$两个处理不是一气呵成的$。“检查”后，“上锁”前可能发生进程切换。

2.11.3 双标志后检查

算法思想:
双标志先检查法的改版。前一个算法的问题是先“检查”后“上锁”，但是这两个操作又无法一气呵成，因此导致了两个进程同时进入临界区的问题。因此，人们又想到先“上锁”后“检查”的方法，来避免上述问题。

bool flag[2]; //表示进入临界区意愿的数组
flag[0] = false;
flag[1] = false;//刚开始设置为两个进程都不想进入临界区
//p0进程
flag[0] = true;//1
while (flag[1]);//2
critical section;//3
flag[0] = false;//4
remainder section;
//p1进程
flag[1] = true;//5 标记为P1进程想要进入临界区
while (flag[0]);//6 如果此时P0想要进入临界区，P1就会一直等待
critical section;//7 访问临界区
flag[1] = false;//8 访问完临界区，修改标记为P1不想要使用临界区
remainder section;

若按照$①⑤②⑥....$的顺序执行，$PO和P1$将都无法进入临界区
因此，双标志后检查法虽然$解决了“忙则等待”$的问题，但是$又违背了“空闲让进”和“有限等待”原则$，会因各进程都长期无法访问临界资源而$产生“饥饿”$现象。
两个进程都争着想进入临界区，但是谁也不让谁，最后谁都无法进入临界区。

2.11.4 $Peterson$算法

算法思想:
双标志后检查法中，两个进程都争着想进入临界区，但是谁也不让谁，最后谁都无法进入临界区。$GaryL.Peterson$想到了一种方法，如果双方都争着想进入临界区，那可以让进程尝试“孔融让梨”，主动让对方先使用临界区。

bool flag[2]; //表示进入临界区意愿的数组
int trun = 0;//trun 表示优先让哪个基础进入临界区
//p0进程
flag[0] = true;//1
trun = 1;//2
while (flag[1] && trun = 1);//3
critical section;//4
flag[0] = false;//5
remainder section;
//p1进程
flag[1] = true;//6 表示自己想要进入临界区
trun = 0;//7 可以让对方优先进入临界区
while (flag[0] && true == 0);//8 对方想进，且最后一次自己“让梨”，那自己就循环等待
critical section;//9 访问临界区
flag[1] = false;//10 访问完临界区，表示自己不想要访问临界区
remainder section;

Peterson算法用软件方法解决了进程互斥问题，$遵循了空闲让进、忙则等待、有限等待三个原则$，但是依然$未遵循让权等待$的原则。
Peterson算法相较于之前三种软件解决方案来说，是最好的，但依然不够好。

2.12 进程互斥的硬件实现方法

2.12.1 中断屏蔽方法

利用“开/关中断指令”实现（与原语的实现思想相同，即在某进程开始访问临界区到结束访问为止都不允许被中断，也就不能发生进程切换，因此也不可能发生两个同时访问临界区的情况)

...
关中断；关中断后即不允许当前进程被中断，也必然不会发生进程切换
临界区；
开中断；直到当前进程访问完临界区，再执行开中断指令，才有可能有别的进程上处理机并访问临界区
...

优点:简单、高效
缺点:不适用于多处理机:只适用于操作系统内核进程，不适用于用户进程〈因为开/关中断指令只能运行在内核态，这组指令如果能让用户随意使用会很危险)

2.12.2 $TestAndSet(TS指令/TSL指令)$

简称TS指令，也有地方称为$TestAndSetLock$指令，或$TSL$指令
$TSL$指令$是用硬件实现的$，执行的过程不允许被中断，只能一气呵成。以下是用c语言描述的逻辑

//布尔型共享变量 lock 表示当前临界区是否被枷锁
//true 表示已加锁，false 表示未加锁
bool TestAndSet(bool *lock) {
    bool old;
    old = *lock;//old表示用来存放 lock 原来的值
    *lock = true;//无论之前是否已加锁，都将 lock 设为 true
    return old;//返回 lock 原来的值
}

//以下是使用 TSL 指令实现互斥的算法逻辑
while (TestAndSet(&lock));//“上锁”并“检查”
临界区代码段...
lock = false;    //“解锁”
剩余代码段...

若刚开始lock 是 false，则$TSL$返回的old值为 false，while循环条件不满足，直接跳过循环，进入临界区。若刚开始lock 是 true，则执行$TLS$后old返回的值为true，while循环条件满足，会一直循环，直到当前访问临界区的进程在退出区进行“解锁”。
相比软件实现方法，$TSL$指令把“上锁”和“检查”操作用硬件的方式变成了一气呵成的原子操作。
优点:实现简单，无需像软件实现方法那样严格检查是否会有逻辑漏洞;适用于多处理机环境
缺点:不满足“让权等待”原则，暂制无法进入临界区的进程会占用CPU并循环执行$TSL$指令，从而导致“忙等”。

2.12.3 $Swap$指令($XCHG$指令)

有的地方也叫Exchange指令，或简称$XCHG$指令。
Swap指令$是用硬件实现的$，执行的过程不允许被中断，只能一气呵成。以下是用C语言描述的逻辑

//Swap 指令的作用是交换两个变量的值
void Swap (bool *a, bool *b) {
    bool temp;
    temp = *a;
    *a = *b;
    *b = temp;
}

//以下是用 Swap 指令实现互斥的算法逻辑
//lock 表示当前临界区是否被加锁
bool old = true;
while (old == true)
    Swap(&lock, &old);
临界代码块...
lock = false;
剩余代码块...

逻辑上来看Swap和$TSL$并无太大区别，都是先记录下此时临界区是否已经被上锁〈记录在old变量上），再将上锁标记lock 设置为true，最后检查old，如果old为 false则说明之前没有别的进程对临界区上锁，则可跳出循环，进入临界区。
优点:实现简单，无需像软件实现方法那样严格检查是否会有逻辑漏洞;适用于多处琪机环境
缺点:不满足“让权等待”原则，暂时无法进入临界区的进程会占用CPU并循环执行$TSL$指令，从而导致“忙等”。

2.13 信号量机制

• 用户进程可以通过使用操作系统提供的$一对原语$来对$信号量$进行操作，从而很方便的实现了进程互斥、进程同步。
• $信号量$其实就是一个变量$(可以是一个整数，也可以是更复杂的记录型变量)$，可以用一个信号量来$表示系统中某种资源的数量$，比如:系统中只有一台打印机，就可以设置一个初值为1的信号量。
• 软件解决方案的主要问题是由“进入区的各种操作无法一气呵成”，因此如果能把进入区、退出区的操作都用“原语”实现，使这些操作能“一气呵成”就能避免问题。
• $一对原语:wait(S)$原语和$signal(S)$原语，可以把原语理解为我们自己写的函数，函数名分别为wait和signal，括号里的$信号量s$其实就是函数调用时传入的一个参数。
• wait、signal 原语常$简称为P、V操作$（来自荷兰语$proberen和verhogen)$。因此，做题的时候常把wait(S)、signal(S)两个操作分别写为$P(S)、V(S)$

2.13.1 整形信号量

用一个$整数型的变量$作为信号量，用来$表示系统中某种资源的数量$。
写普通整数变量的区别:对信号量的操作只有三种,即初始化、P操作、V操作

$Eg$:某计算机系统中有一台打印机…

int S = 1; //初始化整型信号量s，表示当前系统中可用的打印机资源数

void wait (int S) {//wait原语，相当于“进入区”
    while (S <= 0);//如果资源数不够，就会一直循环等待
    S = s - 1;	   //如果资源数够，则占用一个资源
}

void signal (int S) {//signal 原语，相当于“退出区”
    S = S + 1;   //使用完资源后，在退出区释放资源
}

进程$P0$: 进程$P1$：
… …
wait(S); //进入区，申请资源 wait(S);
使用打印机资源…//临界区，访问资源 使用打印机资源…
signal(S); //退出区，释放资源 signal(S);
… …

“检查”和“上锁”一气呵成，避免了并发、异步导致的问题
存在的问题:不满足“让权等待”原则，会发生“忙等”

2.13.2 记录型信号量

整型信号量的缺陷是存在“忙等”问题，因此人们又提出了“记录型信号量”，即用记录型数据结构表示的信号量。

/*记录型信号量的定义*/
typedef struct {
    int value;    //剩余资源数
    struct process *L;//等待队列
} semaphore;

/*某进程需要使用资源时，通过 wait 原语申请*/
void wait (semaphore S) {
    S.value--;
    if (S.value < 0) {
        block (S.L);
    }
}
/*如果剩余资源数不够，使用 block 原语使进程从运行态进入阻塞态，并把挂到信号量S的等待队列(即阻塞队列)中*/

/*进程使用完资源后，通过 signal 原语释放*/
void signal (semaphore S) {
    S.value ++;
    if (S.value <= 0) {
        wakeup(S.L);
    }
}
/*释放资源后，若还有别的进程在等待这种资源，则使用 wakeup 原语唤醒等待队列中的一个进程，该进程从阻塞态，变为就绪态*/

1. 在考研题目中wait(S)、signal(S)也可以记为P(S)、V(S),这对原语可用于$实现系统资源的“申请”和“释放”。$
2. $S.value的初值$表示系统中$某种资源的数目$。
3. 对信号量s的$一次Р操作$意味着进程$请求一个单位的该类资源$，因此需要执行$S.value--$，表示资源数减1，当$S.value<0$时表示该类资源已分配完毕，因此进程应$调用block原语进行自我阻塞$（当前运行的进程从$运行态->阻塞态$)，主动放弃处理机，并插入该类资源的等待队列$s.L$中。可见，该机制$遵循了“让权等待”原则$，不会出现“忙等”现象。
4. 对信号量s的$一次v操作$意味着进程$释放一个单位的该类资源$，因此需要执行$S.value++$，表示资源数加1，若加1后仍是$S.value<=0$，表示依然有进程在等待该类资源，因此应$调用wakeup原语唤醒等待队列中的第一个进程$（被唤醒进程从$阻塞态\to 就绪态$）。

2.13.3 实现进程互斥

1. 分析并发进程的关键活动，划定临界区,(如:对临界资源打印机的访问就应放在临界区)
2. 设置$互斥信号量mutex$，$初值为1$
3. 在临界区之前执行$P(mutex)$
4. 在临界区之后执行$v(mutex)$

/*信号量机制实现互斥*/
semaphore mutex = 1;  // 初始化信号量

P1() {
    ***
    P(mutex);//使用临界区资源需要加锁
    临界区代码段....
    V(mutex);//使用临界资源后需要解锁
    ***
}

P2() {
    ***
    P(mutex);//使用临界区资源需要加锁
    临界区代码段....
    V(mutex);//使用临界资源后需要解锁
    ***
}

注意:对$不同的临界资源$需要$设置不同的互斥信号量$。
$P、V操作必须成对出现$。缺少$P(mutex)$就不能保证临界资源的互斥访问。缺少$V(mutex)$会导致资源永不被释放，等待进程永不被唤醒。

2.13.4 实现进程同步

进程同步:要让各并发进程按要求有序地推进。

P1() {					P2() {
   代码1;					代码4;
   代码2;					代码5;
   代码3;					代码6;
}					   }

比如，$P1、P2$并发执行，由于存在异步性，因此二者交替推进的次序是不确定的。若$P2$的“代码4”要基于$P1$的“代码1”和“代码2”的运行结果才能执行，那么我们就必须保证“代码4”一定是在“代码2”之后才会执行。
这就是进程同步问题，让本来异步并发的进程互相配合，有序推进。

用信号量实现进程同步:

1. 分析什么地方需要实现“同步关系”，即必须保证“一前一后”执行的两个操作（或两句代码)
2. 设置$同步信号量$S,$初始为0$
3. $在“前操作”之后执行V(S)$
4. $在“后操作”之前执行P(S)$

/*信号量机制实现同步*/
semaphore S = 0; //初始化同步信号量，初始化值为0
P1() {					P2() {
   代码1;					P(S);
   代码2;					代码4;
   V(S);				  代码5;
   代码3;					代码6;
}					   }

若先执行到v(S)操作，则S++后S=1。之后当执行到P(S)操作时，由于S=1，表示有可用资源，会执行S–，S的值变回0，$P2$进程不会执行block原语，而是继续往下执行代码4。
若先执行到P(S)操作，由于S=0，S–后S=-1，表示此时没有可用资源，因此P操作中会执行block原语，主动请求阻塞。之后当执行完代码2，继而执行v(S)操作，S++，使s变回0,由于此时有进程在该信号量对应的阻塞队列中，因此会在V操作中执行wakeup原语，唤醒$P2$进程。这样$P2$就可以继续执行代码4了

2.13.5 实现进程的前驱关系

1. 分析问题，画出前驱图，把每一对前驱关系都看成一个同步问题
2. 为每一对前驱关系设置同步信号量，初值为0
3. 在每个"前操作"之后执行V操作
4. 在每个"后操作"之前执行Р操作

2.14 P V操作相关经典问题

2.14.1 生产者消费者问题

问题分析

1. 系统中有一组生产者进程和一组消费者进程，生产者进程每次生产一个产品放入缓冲区，消费者进程每次从缓冲区中取出一个产品并使用。(注:这里的“产品”理解为某种数据)
2. 生产者、消费者共享一个$初始为空、大小为n的缓冲区。$
3. 只有$缓冲区没满$时，生产者才能把产品放入缓冲区，否则必须等待。
4. 只有$缓冲区不空$时，消费者才能从中取出产品，否则必须等待。
5. 缓冲区是临界资源，各进程必须$互斥地访问$。

如何用信号量机制(P、v操作）实现生产者、消费者进程的这些功能呢?
信号量机制可实现互斥、同步、对一类系统资源的申请和释放。

• 互斥：设置初值为1的互斥信号量

• 同步：设置初值为0的同步信号量（实现“一前一后”)

• 对一类系统资源的申请和释放：设置一个信号量，初始值即为资源的数量(本质上也属于“同步问题”，若无空闲资源，则申请资源的进程需要等待别的进程释放资源后才能继续往下执行）

$PV$操作题目分析步骤：

1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。
   问题分析3：（同步关系。缓冲区满时，生产者要等待消费者取走产品）
   问题分析4：(同步关系。缓冲区空时（即没有产品时)，消费者要等待生产者放入产品)
   问题分析5：(互斥)

2. 整理思路。根据各进程的操作流程确定P、V操作的大致顺序。

   ​ 生产者每次要消耗（$P1$)一个空闲缓冲区,
   ​ 并生产（$V2$)一个产品。
   ​ 消费者每次要消耗($P2$）一个产品,
   ​ 并释放一个空闲缓冲区（$V1$)
   ​ 往缓冲区放入/取走产品需要互斥

3. 设置信号量。设置需要的信号量，并根据题目条件确定信号量初值。(互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少)

semaphore mutex = l;//互斥信号量,实现对缓冲区的互斥访问
semaphore empty = n;//同步信号量,表示空闲缓冲区的数量
semaphore full = 0 ;//同步信号量,表示产品的数量，也即非空缓冲区的数量

void producer () {
    while(1) {
        生产一个产品;
        P(empty);
        P(mutex);
        把产品放入缓冲区;
        V(mutex);
        V(full);
    }
}

void consumer() {
    while(1) {
        P(full);
        P(mutex);
        从缓冲区取走一个产品;
        V(mutex);
        V(empty);
        使用产品;
    }
}

对$PV$操作顺序的考虑

void producer () {
    while(1) {
        生产一个产品;
        P(mutex);  //1
        P(empty);  //2
        把产品放入缓冲区;
        V(mutex);
        V(full);
    }
}

void consumer() {
    while(1) {
        P(mutex);  //3
        P(full);   //4
        从缓冲区取走一个产品;
        V(mutex);
        V(empty);
        使用产品;
    }
}

若此时缓冲区内已经放满产品，则empty=o，full=n。
则生产者进程执行①使$mutex$变为o，再执行②，由于已没有空闲缓冲区，因此生产者被阻塞。由于生产者阻塞，因此切换回消费者进程。消费者进程执行③，由于$mutex$为o，即生产者还没释放对临界资源的“锁”，因此消费者也被阻塞。
这就造成了生产者等待消费者释放空闲缓冲区，而消费者又等待生产者释放临界区的情况，生产者和消费者循环等待被对方唤醒,出现“死锁”。
同样的，若缓冲区中没有产品，即full=0，empty=n。按③④①的顺序执行就会发生死锁。
因此,$实现互斥的P操作一定要在实现同步的P操作之后$。
V操作不会导致进程阻塞，因此$两个v操作顺序可以交换$。

2.14.2 多生产者多消费者

问题分析
桌子上有一只盘子，每次只能向其中放入一个水果。爸爸专向盘子中放苹果，妈妈专向盘子中放橘子，儿子专等着吃盘子中的橘子，女儿专等着吃盘子中的苹果。只有盘子空时，爸爸或妈妈才可向盘子中放一个水果。仅当盘子中有自己需要的水果时，儿子或女儿可以从盘子中取出水果。

1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。

   • 互斥关系:
     对缓冲区（盘子)的访问要互斥地进行

   • 同步关系（一前一后）:
     1.父亲将苹果放入盘子后，女儿才能取苹果
     2.母亲将橘子放入盘子后，儿子才能取橘子
     3．只有$盘子为空$时，$父亲或母亲$才能放入水果

     “盘子为空”这个事件可以由儿子或女儿触发，事件发生后才允许父亲或母亲放水果

2. 整理思路。根据各进程的操作流程确定P、V操作的大致顺序。

   互斥:在临界区前后分别$PV$
   同步:前V后P

3. 设置信号量。设置需要的信号量，并根据题目条件确定信号量初值。(互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少)
   互斥关系：$（mutex=1）$ 对缓冲区(盘中)的访问要互斥地进行
   同步关系：$(apple=0)$ 表示同步关系1中地同步信号量
   $(orange=0)$表示同步关系2中地同步信号量
   ($plate=1$) 表示同步关系3中地同步信号量

semaphore mutex = 1;//实现互斥访问盘子（缓冲区)
semaphore apple = 0 ;//盘子中有几个苹果
semaphore orange = 0 ;//盘子中有几个橘子
semaphore plate = 1;//盘子中还可以放多少个水果

dad (){
	while (1){
        准备一个苹果;
         P(plate);
         把萃果放入盘子;
         V(apple);
	}
}

mom (){
	while(1）{
		准备一个橘子;
        P(plate);
        把橘子放入盘子;
        V(orange);
    }
}

doughter (){
	while (1）{
		P(apple);
		从盘中取出苹果;
         V(plate);
		吃掉苹果;
    }
}

son (){
    while(1）{
        P(orange);
        从盘中取出橘子;
        V(plate);
        吃掉橘子;
    }
}

分析:刚开始，儿子、女儿进程即使上处理机运行也会被阻塞。如果刚开始是父亲进程先上处理机运行，则:父亲P(plate)，可以访问盘子→母亲P(plate)，阻塞等待盘子→父亲放入苹果V(apple)，女儿进程被唤醒，其他进程即使运行也都会阻塞，暂时不可能访问临界资源（盘子)→女儿P(apple)，访问盘子，V(plate)，等待盘子的母亲进程被唤醒→母亲进程访问盘子（其他进程暂时都无法进入临界区）→…
结论:
即使不设置专门的互斥变量$mutex$,也不会出现多个进程同时访问盘子的现象
原因在于:本题中的缓冲区大小为1，在任何时刻，apple、 orange、plate三个同步信号量中最多只有一个是1。因此在任何时刻,最多只有一个进程的P操作不会被阻塞，并顺利地进入临界区…

2.14.3 抽烟者问题

问题分析
假设一个系统有$三个抽烟者进程$和一个供应者进程。每个抽烟者不停地卷烟并抽掉它，但是要卷起并拍掉一支烟，抽烟者需要有三种材料:烟草、纸和胶水。三个抽烟者中，$第一个拥有烟草、第二个拥有纸、第三个拥有胶水$。供应者进程无限地提供三种材料，供应者每次将两种材料放桌子上，$拥有剩下那种材料的抽烟者卷一根烟并抽掉它$，并给$供应者进程一个信号告诉完成了$，供应者就会放另外两种材料再桌上，这个过程一直重复（$让三个抽烟者轮流地抽烟$)

本质上这题也属于“生产者-消费者”问题，更详细的说应该是“可生产多种产品的单生产者-多消费者”。

1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。

   • 互斥关系:

     卓子可以抽象为容量为1的缓冲区,要互斥访问

   • 同步关系（从事件的角度来看）:
     组合一: 纸+胶水
     组合二: 烟草+胶水
     组合三: 烟草+纸

     桌上有组合一→第一个抽烟者取走东西
     桌上有组合二→第二个抽烟者取走东西
     桌上有组合三→第三个抽烟者取走东西
     发出完成信号→供应者将下一个组合放到桌上

2. 整理思路。根据各进程的操作流程确定P、V操作的大致顺序。

   互斥:在临界区前后分别$PV$
   同步:前V后P

3. 设置信号量。设置需要的信号量，并根据题目条件确定信号量初值。(互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少)
   互斥关系：$（mutex=1）$ 对缓冲区(盘中)的访问要互斥地进行
   同步关系：$(offer1=0)$表示同步组合1中地同步信号量
   $(offer2=0)$表示同步组合2中地同步信号量
   ($offer3=0$) 表示同步组合3中地同步信号量
   $(finish=0)$ 表示发展完成信号的同步信号量

semaphore offer1 =0;//桌上组合一的数量
semaphore offer2 =0 ;//桌上组合二的数量
semaphore offer3 =0;//桌上组合三的数量
semaphore finish = 0;//抽烟是否完成
int i = 0;//用于实现”三个抽烟者轮流抽烟”

provider () {
    while(1){
        if(i==0){
        	将组合一放桌上;
             V(offer1) ;
        }else if (i==1){
        	将组合二放桌上;
            V(offer2);
        }else if(i==2){
        	将组合三放桌上;
            V(offer3);
        }
        i = (i+1)%3;
        P(finish);
    }
)

smokezl(){
    while(1){
    	P(offer2);
        从桌上拿走组合二;卷烟;抽掉;
        V(finish);
    }
}

smokezl(){
    while(1){
    	P(offer2);
        从桌上拿走组合二;卷烟;抽掉;
        V(finish);
    }
}
          
smokezl(){
    while(1){
    	P(offer3);
        从桌上拿走组合三;卷烟;抽掉;
        V(finish);
    }
}

是否需要设置专门的互斥信号量？
缓冲区大小为1，同一时刻，四个同步信号量中至多有一个的值为1；

2.14.4 读者写者问题

问题分析
有读者和写者两组并发进程，共享一个文件，当两个或两个以上的读进程同时访问共享数据时不会产生副作用，但若某个写进程和其他进程（读进程或写进程）同时访问共享数据时则可能导致数据不一致的错误。
因此要求:①$允许多个读者可以同时对文件执行读操作$;
②$只允许一个写者往文件中写信息$;
③$任一写者在完成写操作之前不允许其他读者或写者工作$;
④$写者执行写操作前，应让已有的读者和写者全部退出$。

1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。

   • 两类进程：写进程、读进程

   • 互斥关系: 写进程一写进程、写进程―读进程。读进程与读进程不存在互斥问题。

​

2. 整理思路。根据各进程的操作流程确定P、V操作的大致顺序。

   写者进程和任何进程都互斥，设置一个互斥信号量$rw$，在写者访问共享文件前后分别执行P、v操作读者进程和写者进程也要互斥，因此读者访问共享文件前后也要对$rw$执行P、v操作。
   如果所有读者进程在访问共享文件之前都执行P($rw$)操作，那么会导致各个读进程之间也无法同时访问文件。

   解决方案：
   $P(rw)和V(rw)$其实就是对共享文件的“加锁”和“解锁”。既然各个读进程需要同时访问，而读进程与写进程又必须互斥访问，那么我们可以让第一个访问文件的读进程“加锁”，让最后一个访问完文件的读进程“解锁”。可以设置一个整数变量count来记录当前有几个读进程在访问文件。

semaphore rw=l;//用于实现对文件的互斥访问。表示当前是否有进程在访问共享文件
int count = 0;//记录当前有几个读进程在访问文件
semaphore mutex = l;//用于保证对count变量的互斥访问

writer (){
    while (1){
        P (rw);//写之前“加锁”
        写文件...
        v (rw) ;//写之后"解锁”
    }
}

reader {
    while(1){
       P(mutex);	//各读进程互斥访问count
        if(count==0)
        	P(rw) ; //第一个读进程负责”"加锁”
        count++;	//访问文件的读进程数+1
        V(mutex);
        读文件...
        P (mutex); 	//各读进程互斥访问count
        count--;	//访问文件的读进程数-1
        if(count==0)
	       V(rw); 	//最后一个读进程负责"解锁”
        V(mutex);
    }
}

潜在的问题:
只要有读进程还在读，写进程就要一直阻塞等待，可能“饿死”。因此，这种算法中，读进程是优先的

semaphore rw=1;//用于实现对文件的互斥访问。表示当前是否有进程在访问共享文件
int count = 0;//记录当前有几个读进程在访问文件
semaphore mutex = 1;//用于保证对count变量的互斥访问
semaphore w = 1;//用于实现“写优先”

writer (){
    while (1){
        P(w);
        P (rw);//写之前“加锁”
        写文件...
        v (rw) ;//写之后"解锁”
        V(w);
    }
}

reader {
    while(1){
       P(w);
       P(mutex);	//各读进程互斥访问count
        if(count==0)
        	P(rw) ; //第一个读进程负责”"加锁”
        count++;	//访问文件的读进程数+1
        V(mutex);
        V(w);
        读文件...
        P (mutex); 	//各读进程互斥访问count
        count--;	//访问文件的读进程数-1
        if(count==0)
	       V(rw); 	//最后一个读进程负责"解锁”
        V(mutex);
    }
}

2.13.5 哲学家问题

问题分析
一张圆桌上坐着5名哲学家，每两个哲学家之间的桌上摆一根筷子，桌子的中间是一碗米饭。哲学家们倾注毕生的精力用于思考和进餐，哲学家在思考时，并不影响他人。只有当哲学家饥饿时，才试图拿起左、右两根筷子（一根一根地拿起)。如果筷子已在他人手上，则需等待。饥饿的哲学家只有同时拿起两根筷子才可以开始进餐，当进餐完毕后，放下筷子继续思考。

1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。

   • 互斥关系:系统中有5个哲学家进程，5位哲学家与左右邻居对其中间筷子的访问是互斥关系。

2. 整理思路。

   这个问题中只有互斥关系，但与之前遇到的问题不同的事，每个哲学家进程需要同时持有两个临界资源才能开始吃饭。如何$避免$临界资源分配不当造成的$死锁现象$，是哲学家问题的精髓

3. 信号量设置。定义互斥信号量数组chopstick[5]={1,1,1,1,1}用于实现对5个筷子的互斥访问。并对哲学家按0~4编号，哲学家i左边的筷子编号为i，右边的筷子编号为(i+1)%5。

如何防止死锁的发生呢?

1. 可以对哲学家进程施加一些限制条件,比如最多允许四个哲学家同时进餐。这样可以保证至少有一个哲学家是可以拿到左右两只筷子的

2. 要求奇数号哲学家先拿左边的筷子，然后再拿右边的筷子，而偶数号哲学家刚好相反。用这种方法可以保证如果相邻的两个奇偶号哲学家都想吃饭，那么只会有其中一个可以拿起第一只筷子，另一个会直接阻塞。这就避免了占有一支后再等待另一只的情况。

3. 仅当一个哲学家左右两支筷子都可用时才允许他抓起筷子。

   各哲学家拿筷子这件事必须互斥的执行。这就保证了即使一个哲学家在拿筷子拿到一半时被阻塞，也不会有别的哲学家会继续尝试拿筷子。这样的话，当前正在吃饭的哲学家放下筷子后，被阻塞的哲学家就可以获得等待的筷子了。

/*以方法3为例*/
semaphore chopstick[5]={1,1,1,1,1};
semaphore mutex = l;//互斥地取筷子
Pi (){//i号哲学家的进程
    while(1){
        P (mutex);
        P (chopstick[i]);//拿左
        P (chopstick [ (i+1)%5]); //拿右
        v (mutex);
        吃饭..
        v (chopstick[i]); //放左
        v(chopstick[ (i+1)%5]); //放右
        思考...
    }
)

2.15 管程

1.15.1 为什么要引入管程

信号量机制存在的问题:编写程序困难、易出错
1973年，Brinch Hansen首次在程序设计语言(Pascal)中引入了“管程”成分——一种高级同步机制

1.15.2 管程的定义和基本特征

管程是一种特殊的软件模块，有这些部分组成:

1. 局部于管程的$共享数据结构$说明;
2. 对该数据结构进行操作的$一组过程$;
3. 对局部于管程的共享数据设置初始值的语句;
4. 管程有一个名字。

管程的基本特征:

1. 局部于管程的数据只能被局部于管程的过程所访问;
2. 一个进程只有通过调用管程内的过程才能进入管程访问共享数据;
3. $每次仅允许一个进程在管程内执行某个内部过程。$

1.15.3 用管程解决生产者消费者问题

monitor Producerconsumer
    condition full,empty;//条件变量用来实现同步（排队)
    int count=0;//缓冲区中的产品数
    void insert ( Item item) { //把产品item放入缓冲区
        if ( count == N)
        	wait (full);
        count++;
        insert_item (item);
        if ( count == 1)
        	signal(empty);
    }
    Item remove () i {//从缓冲区中取出一个产品
        if (count == 0)
    		wait (empty);count--;
    	if ( count == N-1)
            signal(full);
    	return remove_item( );}
end monitor;

//生产者进程
producer (){
    while(1){
		item =生产一个产品;
		ProdecerConsumer.insert (item);
    }
}

//消费者进程
consumer (){
    while(1){
		item = Prodecerconsumer.remove ( );
        消费产品item;
    }
}

引入管程的目的无非就是要更方便地实现进程互斥和同步。

1. 需要在管程中定义共享数据（如生产者消费者问题的缓冲区)
2. 需要在管程中定义用于访问这些共享数据的“入口”――其实就是一些函数（如生产者消费者问题中，可以定义一个函数用于将产品放入缓冲区，再定义一个函数用于从缓冲区取出产品)
3. 只有$通过这些特定的“入口”才能访问共享数据$
4. 管程中有很多“入口”，但是$每次只能开放其中一个“入口”，$并且$只能让一个进程或线程进入$(如生产者消费者问题中，各进程需要互斥地访问共享缓冲区。管程的这种特性即可保证一个时间段内最多只会有一个进程在访问缓冲区。$注意:这种互斥特性是由编译器负责实现的，程序员不用关心)$
5. 可在管程中设置$条件变量$及$等待/唤醒操作$以解决同步问题。可以让一个进程或线程在条件变量
   上等待（$此时，该进程应先释放管程的使用权，也就是让出“入口”)$﹔可以通过唤醒操作将等待在条件变量上的进程或线程唤醒。
6. 程序员可以用某种特殊的语法定义一个管程（比如: monitor ProducerConsumer …end monitor;）,之后其他程序员就可以使用这个管程提供的特定“入口”很方便地使用实现进程同步/互斥了。

1.15.4Java中类似于管程的机制

Java 中，如果用关键字synchronized来描述一个函数，那么这个函数同一时间段内只能被一个线程调用

static class monitor {
    private Item buffer[] = new Item[N];
	private int count = 0;
    
    public synchronized void insert (Item item) {
       	......
    }
}

2.16 死锁

2.16.1 死锁的定义

在并发环境下，各进程因竞争资源而造成的一种互相等待对方手里的资源，导致各进程都阻塞，都无法向前推进的现象，就是“死锁”发生死锁后若无外力干涉,这些进程都将无法向前推进

2.16.2 进程死锁、饥饿、死循环的区别

$$\begin{array}{lll}& 共同点& 区别\\ 死锁& 都是进程无法顺利向前推进的现象& 死锁一定是“循环等待对方手里的资源”导致的\\ & (故意设设计的死循环除外)& 因此如果有死锁现象，那至少有两个或两个以上的进程同时发生死锁。\\ & & 另外，发生死锁的进程一定处于阻塞态。\\ 饥饿& & 可能只有一个进程发生饥饿。\\ & & 发生饥饿的进程既可能是阻塞态(如长期得不到需要的l/o设备)，\\ & & 也可能是就绪态(长期得不到处理机)\\ 死循环& & 可能只有一个进程发生死循环。\\ & & 死循环的进程可以上处理机运行（可以是运行态），只不过无法像期待\\ & & 的那样顺利推进。死锁和饥饿问题是由于操作系统分配资源的策略不合理导致的，\\ & & 而死循环是由代码逻辑的错误导致的。\\ & & 死锁和饥饿是管理者（操作系统）的问题，死循环是被管理者的问题。\end{array}$$

2.16.3死锁产生的必要条件

产生死锁必须同时满足一下四个条件，只要其中任一条件不成立，死锁就不会发生。

1. $互斥条件$:只有对必须互斥使用的资源的争抢才会导致死锁（如哲学家的筷子、打印机设备）。像内存、扬声器这样可以同时让多个进程使用的资源是不会导致死锁的（因为进程不用阻塞等待这种资源)。
2. $不剥夺条件$:进程所获得的资源在未使用完之前，$不能由其他进程强行夺走$，只能主动释放。
3. 请求和保持条件:进程$已经保持了至少一个资源$，但又提出了新的资源$请求$，而该资源又被其他进程占有，此时请求进程被阻塞，但又对自己己有的资源$保持$不放。
4. $循环等待条件$:存在一种进程$资源的循环等待链$，链中的每一个进程己获得的资源同时被下一个进程所请求。
   $注意!发生死锁时一定有循环等待，但是发生循环等待时未必死锁$（循环等待是死锁的必要不充分条件)
   如果同类资源数大于1，则即使有循环等待，也未必发生死锁。但如果系统中每类资源都只有一个，那循环等待就是死锁的充分必要条件了。

2.16.4 什么时候会发生死锁

1. 对系统资源的竞争。各进程对不可剥夺的资源（如打印机）的竞争可能引起死锁，对可剥夺的资源(CPU)的竞争是不会引起死锁的。
2. 进程推进顺序非法。请求和释放资源的顺序不当，也同样会导致死锁。例如，并发执行的进程P1、P2分别申请并占有了资源R1、R2，之后进程P1又紧接着申请资源R2，而进程P2又申请资源R1，两者会因为申请的资源被对方占有而阻塞，从而发生死锁。
3. 信号量的使用不当也会造成死锁。如生产者-消费者问题中，如果实现互斥的P操作在实现同步的P操作之前，就有可能导致死锁。(可以把互斥信号量、同步信号量也看做是一种抽象的系统资源)

总之，对不可剥夺资源的不合理分配，可能导致死锁。

2.17 死锁的处理策略

1. 预防死锁。破坏死锁产生的四个必要条件中的一个或几个。
2. 避免死锁。用某种方法防止系统进入不安全状态，从而避免死锁（银行家算法)
3. 死锁的检测和解除。允许死锁的发生，不过操作系统会负责检测出死锁的发生，然后采取某种措施解除死锁。

2.17.1 预防死锁

破坏互斥条件

$互斥条件$:只有对必须互斥使用的资源的争抢才会导致死锁。

如果把只能互斥使用的资源改造为允许共享使用，则系统不会进入死锁状态。比如:$SPOOLing技术$。操作系统可以采用SPOOLing 技术把独占设备在逻辑上改造成共享设备。
比如，用SPOOLing技术将打印机改造为共享设备…
进程1还没用完打印机之前，进程2申请使用打印机会阻塞
使用了SPOOLing技术后，在各进程看来，自己对打印机资源的使用请求立即就被接收处理
了，不需要再阻塞等待

该策略的$缺点$:并不是所有的资源都可以改造成可共享使用的资源。并且为了系统安全，很多地方还必须保护这种互斥性。因此，$很多时候都无法破坏互斥条件$。

破坏不剥夺条件

$不剥夺条件$:进程所获得的资源在未使用完之前，不能由其他进程强行夺走，只能主动释放。

破坏不剥夺条件:
方案一:当某个进程请求新的资源得不到满足时，它必须立即释放保持的所有资源，待以后需要时再重新申请。也就是说，即使某些资源尚未使用完，也需要主动释放，从而破坏了不可剥夺条件。
方案二:当某个进程需要的资源被其他进程所占有的时候，可以由操作系统协助，将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级（比如:剥夺调度方式，就是将处理机资源强行剥夺给优先级更高的进程使用)

该策略的$缺点$:

1. 实现起来比较复杂。
2. 释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源，如CPU。
3. 反复地申请和释放资源会增加系统开销，降低系统吞吐量。
4. 若采用方案一，意味着只要暂时得不到某个资源，之前获得的那些资源就都需要放弃，以后再重新申请。如果一直发生这样的情况，就会导致进程饥饿。

破坏请求和保持条件

$请求和保持条件$:进程$已经保持了至少一个资源$，但又提出了新的资源$请求$，而该资源又被其他进程占有，此时请求进程被阻塞，但又对自己已有的资源$保持$不放。

可以采用$静态分配方法$，即进程在运行前一次申请完它所需要的全部资源，在它的资源未满足前，不让它投入运行。一旦投入运行后，这些资源就一直归它所有，该进程就不会再请求别的任何资源了。

该策略实现起来简单，但也有明显的$缺点$:
有些资源可能只需要用很短的时间，因此如果进程的整个运行期间都一直保持着所有资源，就会造成严重的资源浪费，$资源利用率极低$。另外，该策略也有$可能导致某些进程饥饿$。

破坏循环等待条件

$循环等待条件$:存在一种进程$资源的循环等待链$，链中的每一个进程已获得的资源同时被下一个进程所请求。

可采用$顺序资源分配法$。首先给系统中的资源编号，规定每个进程$必须按编号递增的顺序请求资源$，同类资源（即编号相同的资源）一次申请完。

原理分析:一个进程只有已占有小编号的资源时，才有资格申请更大编号的资源。按此规则，已持有大编号资源的进程不可能逆向地回来申请小编号的资源，从而就不会产生循环等待的现象。
假设系统中共有10个资源，编号为1,2,…10
在任何一个时刻，总有一个进程拥有的资源编号是最大的，那这个进程申请之后的资源必然畅通无阻。因此，不可能出现所有进程都阻塞的死锁现象

该策略的$缺点$:
1.不方便增加新的设备，因为可能需要重新分配所有的编号;
2.进程实际使用资源的顺序可能和编号递增顺序不一致，会导致资源浪费;
3.必须按规定次序申请资源，用户编程麻烦。

2.17.2 避免死锁

安全序列

所谓$安全序列$，就是指如果系统按照这种序列分配资源，则每个进程都能顺利完成。只要能找出一个安全序列，系统就是$安全状态$。当然，$安全序列可能有多个$。

系统的不安全状态与死锁的联系

如果分配了资源之后，系统中找不出任何一个安全序列，系统就进入了$不安全状态$。这就意味着之后$可能$所有进程都无法顺利的执行下去。当然，如果有进程提前归还了一些资源，那$系统也有可能重新回到安全状态$，不过我们在分配资源之前总是要考虑到最坏的情况。

如果系统处于$安全状态$，就$一定不会$发生$死锁$。如果系统进入$不安全状态$，就$可能$发生$死锁$（处于不安全状态未必就是发生了死锁，但发生死锁时一定是在不安全状态)
因此可以$在资源分配之前预先判断这次分配是否会导致系统进入不安全状态$，以此决定是否答应资源分配请求。这也是“$银行家算法$”的核心思想。

银行家算法

银行家算法是荷兰学者Dijkstra为银行系统设计的，以确保银行在发放现金贷款时，不会发生不能满足所有客户需要的情况。后来该算法被用在操作系统中，用于$避免死锁$。
$核心思想$:在进程提出资源申请时，先预判此次分配是否会导致系统进入不安全状态。如果会进入不安全状态，就暂时不答应这次请求，让该进程先阻塞等待。

可以把单维的数字拓展为多维的向量。
比如:系统中有5个进程 P0~P4，3种资源 R0~R2，初始数量为(10,5,7)，则某一时刻的情况可表示如下:
$$\begin{array}{llll}进程& 最大需求& 已分配& 最多还需\\ P0& (7,5,3)& (0,1,0)& (7,4,3)\\ P0& (3,2,2)& (2,0,0)& (1,2,2)\\ P0& (9,0,2)& (3,0,2)& (6,0,0)\\ P0& (2,2,2)& (2,1,1)& (0,1,1)\\ P0& (4,3,3)& (0,0,2)& (4,3,1)\end{array}$$
资源总数(10,5,7)，剩余可用资源(3,3,2)
思路:尝试找出一个安全序列…
依次检查剩余可用资源(3,3,2)是否能满足各进程的需求
可满足P1需求，将P1加入安全序列，并更新剩余可用资源值为(5,3,2)
依次检查剩余可用资源(5,3,2)是否能满足剩余进程$（不包括已加入安全序列的进程）$的需求可满足P3需求，将P3加入安全序列，并更新剩余可用资源值为(7,4,3)
依次检查剩余可用资源(7,4,3)是否能满足剩余进程$（不包括已加入安全序列的进程）$的需求.
…
以此类推，共五次循环检查即可将5个进程都加入安全序列中，最终可得一个安全序列。 { P 1 ， P 3 ， P 0 ， P 2 ， P 4 } {\color{red}\{P1，P3，P0，P2，P4\}} {P1，P3，P0，P2，P4}
该算法称为$安全性算法$。可以很方便地用代码实现以上流程，每一轮检查都从编号较小的进程开始检查。实际做题时可以更快速的得到安全序列。

再看一个找不到安全序列的例子:
$$\begin{array}{llll}进程& 最大需求& 已分配& 最多还需\\ P0& (8,5,3)& (0,1,0)& (8,4,3)\\ P0& (3,2,2)& (2,0,0)& (1,2,2)\\ P0& (9,5,2)& (3,0,2)& (6,5,0)\\ P0& (2,2,2)& (2,1,1)& (0,1,1)\\ P0& (4,3,6)& (0,0,2)& (4,3,4)\end{array}$$
资源总数(10,5,7)，剩余可用资源(3,3,2)
经对比发现，(3,3,2）可满足P1、P3，说明无论如何，这两个进程的资源需求一定是可以依次被满足的，因此P1、P3一定可以顺利的执行完，并归还资源。可把P1、P3先加入安全序列。
(2,0,0)+(2,1,1)+(3,3,2)= (7,4,3)
剩下的Po需要(8,4,3)，P2需要(6,5,0)，P4需要(4,3,4)任何一个进程都不能被完全满足
于是，无法找到任何一个安全序列，说明此时系统处于$不安全状态，有可能发生死锁$。

代码实现

假设$系统中有n个进程，m种资源$
每个进程在运行前先声明对各种资源的最大需求数，则可用一个$n\ast m$ 的矩阵（可用二维数组实现）表示所有进程对各种资源的最大需求数。不妨称为$最大需求矩阵Max$，Max[i, j]=K表示进程Pi最多需要K个资源Rj。同理，系统可以用一个$n\ast m$的$分配矩阵Allocation$表示对所有进程的资源分配情况。Max- Allocation =$Need矩阵$，表示各进程最多还需要多少各类资源。另外，还要用一个$长度为m的一维数组Available$表示当前系统中还有多少可用资源。
某进程Pi向系统申请资源，可用一个$长度为m的一维数组Reques{t}_i$表示本次申请的各种资源量。
可用$银行家算法$预判本次分配是否会导致系统进入不安全状态:

1. 如果$Reques{t}_i[j]\le Need[i,j](0\le j\le m)$便转向2.;否则认为出错。

2. 如果$Reques{t}_i[j]\le Available[j](0\le j\le m)$，便转向3.;否则表示尚无足够资源，Pi必须等待。

3. 系统$试探着$把资源分配给进程Pi，并修改相应的数据（$并非真的分配，修改数值只是为了做预判$)
   $$\begin{gathered} Available=Available-Reques{t}_i; \\ Allocation[i,j]=Allocation[i,j]+Reques{t}_i[j]; \\ Need[i,j]=Need[i,j]-Reques{t}_i[j] \end{gathered}$$

4. 操作系统执行$安全性算法$，检查此次资源分配后，系统$是否处于安全状态$。若安全，才正式分配;否则，恢复相应数据，让进程阻塞等待。

2.17.3 死锁的检测和解除

如果系统中既不采取预防死锁的措施，也不采取避免死锁的措施，系统就很$可能发生死锁$。在这种情况下，系统应当提供两个算法:
①死锁检测算法:用于检测系统状态，以确定系统中是否发生了死锁。
②死锁解除算法:当认定系统中己经发生了死锁，利用该算法可将系统从死锁状态中解脱出来。

死锁的检测

为了能对系统是否已发生了死锁进行检测，必须:
①用$某种数据结构$来保存资源的请求和分配信息;
②提供$一种算法$，利用上述信息来检测系统是否已进入死锁状态。
$$数据结构:资源分配图\{\begin{array}{l}两种结点\{\begin{array}{l}进程结点：对应一个进程\\ 资源节点：对应一类资源，一类资源可能有很多\end{array}\\ 两种边\{\begin{array}{l}进程结点-->资源结点：表示进程想申请几个资源(每条边代表一个)\\ 资源结点-->进程结点：表示已经为进程分配了几个资源(每条边代表一个)\end{array}\end{array}$$
般用矩形表示资源结点,

如果系统中剩余的可用资源数足够满足进程的需求，那么这个进程暂时是不会阻塞的，可以顺利地执行下去。如果这个进程执行结束了把资源归还系统，就可能使某些正在等待资源的进程被激活，并顺利地执行下去。相应的，这些被激活的进程执行完了之后又会归还一些资源，这样可能又会激活另外一些阻塞的进程…

如果按上述过程分析，最终$能消除所有边$，就称这个图是$可完全简化的$。此时$一定没有发生死锁$（相当于能找到一个安全序列)

如果最终$不能消除所有边$，那么此时就是发生了$死锁$

检测死锁的算法:

1. 在资源分配图中，找出既不阻塞又不是孤点的进程Pi(即找出一条有向边与它相连，且该有向边对应资源的申请数量小于等于系统中已有空闲资源数量。如下图中，R1没有空闲资源，R2有一个空闲资源。若所有的连接该进程的边均满足上述条件，则这个进程能继续运行直至完成，然后释放它所占有的所有资源）。消去它所有的请求边和分配变，使之称为孤立的结点。在下图中，P1是满足这一条件的进程结点，于是将P1的所有边消去。
2. 进程Pi所释放的资源，可以唤醒某些因等待这些资源而阻塞的进程，原来的阻塞进程可能变为非阻塞进程。在下图中，2就满足这样的条件。根据1）中的方法进行一系列简化后，若能消去途中所有的边，则称该图是$可完全简化的$。

$死锁定理$:如果某时刻系统的资源分配图是$不可完全简化的$，那么此时系统$死锁$

死锁的解除

一旦检测出死锁的发生，就应该立即解除死锁。
补充:并不是系统中所有的进程都是死锁状态，用死锁检测算法$化简资源分配图后，还连着边的那些进程就是死锁进程$
解除死锁的主要方法有:

1. $资源剥夺法$。挂起（暂时放到外存上）某些死锁进程，并抢占它的资源，将这些资源分配给其他的死锁进程。但是应防止被挂起的进程长时间得不到资源而饥饿。
2. $撤销进程法（或称终止进程法）$。强制撤销部分、甚至全部死锁进程，并剥夺这些进程的资
   源。这种方式的优点是实现简单，但所付出的代价可能会很大。因为有些进程可能已经运行了很长时间，已经接近结束了，一旦被终止可谓功亏一篑，以后还得从头再来。
3. $进程回退法$。让一个或多个死锁进程回退到足以避免死锁的地步。这就要求系统要记录进程的历史信息，设置还原点。