🌈个人主页：godspeed_lucip
🔥 系列专栏：OS从基础到进阶

---

---

1 进程同步

⛵1.1 吸烟者问题

✈️1.1.1 问题描述

✈️1.1.2 问题分析

1.1.2.1 关系分析（确定同步、互斥关系）

我们将供应者分别提供的两样东西视为一体，即：组合1（烟草，纸）、组合2（烟草，胶水）、组合3（纸、胶水）。吸烟者分别需要其中的一种组合
（1）进程
共有四个进程：供应者、吸烟者1、2、3
（2）同步关系
吸烟者1只有在供应者供应组合1之后才可以取走东西。吸烟者2、3同理。
（3）互斥关系
三个吸烟者必须轮流的吸烟（或者说：供应者只有在吸烟者吸完之后才可以再次供应原材料）

1.1.2.2 整理思路（确定PV操作的大致顺序）

每种关系都需要有一个信号量，同步关系的三个关系为offer1、offer2、offer3，互斥关系为finish。
供应者供应了offer1后（V操作），吸烟者才可以拿offer1（P操作）。只有当三个吸烟者之一吸完烟之后（P操作），供应者才可以供应东西（V操作）

1.1.2.3 设置信号量（确定信号量初值）

初始时桌子上应该是没有东西的，所以Offer1、2、3的初值都是0。初始时也没有人吸烟，所以finish的初值也为0。此外，由于题目说明吸烟者轮流吸烟，所以还需要一个控制变量，我们设置为整型变量（1代表吸烟者1，2代表吸烟者2，3代表吸烟者3）

✈️1.1.3 代码

🛰️1.1.3.1 吸烟者

以吸烟者1为例：
吸烟者必须先查看桌子上是否有物品1，进行P（offer1），如果没有，则进入睡眠队列，只有当供应者提供了物品1时才苏醒；如果有就拿走吸完，执行V（finish）操作。
其他吸烟者同理

🛰️1.1.3.2 供应者

通过i的变化循环的为每个吸烟者提供材料。以材料1为例，每供应一个材料，就需要将材料的数量+1，执行V（offer1）操作。供应完之后，就应该等待吸烟者吸完，执行P（finish）操作。

🛰️1.1.3.3 改进

事实上，由于缓冲区的大小为1，四个同步信号量中至多只有一个为1，所以finish互斥信号量是不必要的。

✈️1.1.4 总结

可以生产多种产品的单生产者

⛵1.2 读者-写者问题

🛩️1.2.1 问题描述

即：读操作可以同时进行，写操作只可以单独进行

🛩️1.2.2 问题分析

🛰️1.2.2.1 关系分析（确定同步、互斥关系）

（1）进程
共有2个进程，即：读进程、写进程
（2）同步关系
读进程-读进程
（3）互斥关系
读进程-写进程
写进程-写进程

🛰️1.2.2.2 整理思路（确定PV操作的大致顺序）

1. 实现读写互斥
   为了实现读、写的互斥访问，可以设置一个互斥信号量rw，读操作、写操作之前都需要对其进行P操作。但是这样又会造成读进程只可以互斥的访问文件。

2. 实现读读同步
   可以增加一个表示读进程数量的变量count。

读进程在访问文件前首先检查count是不是为0：
①如果是，代表该进程是第一个读的，所以需要对文件进行加锁，
②如果不是，代表之前已经有读进程对文件加锁，可以直接读取，并使count+1代表自己在读取文件

进程对文件的访问结束之后会使count-1，代表自己访问结束，并检查count是不是为0：
①如果是，代表自己是最后一个停止访问文件的，应该对文件解锁，执行V操作，
②如果不是，代表后面还有读进程在读取文件，对文件的解锁应该由后面的文件进行，自己可以直接退出。
如图：
（读进程）

（写进程）

3. 让读不阻塞

试想，当一个读进程甲执行完对count的检查并准备执行P(rw)时，进程被切换到读进程乙，读进程乙执行完P(rw），此时rw=0，后续进程被切换回读进程甲时，它发现rw已经等于0，于是被阻塞在那里。
出现这种情况的原因是因为进程对count的检查并不是连续的。于是可以增加一个互斥信号量mutex用于实现对count的互斥访问。
读进程在读文件前，执行P(mutex)操作，对count进行访问，即：初始查看count是否=0与使count+1时需要加锁，以及最后的对count-1与检查count是否为0时需要加锁。如图
（读进程）

4. 让写不饿死

试想，当一直不断有文件读取文件时，写操作就无法完成。因此，还需要设置一个互斥信号量w，读、写进程在执行操作前对需要对这个信号量加锁，在操作完成之后都需要将这个信号量解锁。如图。此时读进程不再是可以源源不断的占用处理机了，写进程也可以与读进程”同台竞争“处理机的使用机会。
（读进程）

（写进程）

5. 验证

接下来，我们对不同的情况进行依次分析
①读甲-读乙
读甲首先执行P(w)，对w加锁，接着执行后续操作实现对count的访问，之后将w解锁。此时读乙就可以进入到文件的读取中。实现了读操作的同步
②写甲-写乙
写甲首先执行P(w)，将w加锁。之后在写操作完成之后才解锁，写乙才可以对文件进行写操作。实现了写操作的异步
③写甲-读乙
写甲首先执行P(w)，将w加锁。之后在写操作完成之后才解锁，读乙才可以对文件进行读操作。实现了读写操作的异步
④读乙-写甲-读丙
读乙首先对w加锁，写甲等待w解锁，当读乙解锁后写甲就可以写，即使进程被切换到读丙，读丙也只可以等待写甲队w的解锁。这样，就实现了写操作不被读操作饿死。
⑤写甲-读乙-写丙
与上述分析类似，注意到：w本质上是实现了读写操作的公平性，即：读操作不会打断写操作。

🛰️1.2.2.3 设置信号量

初始时，文件有一个，没有被分给任何一个进程，rw为1；初始时没有进程读文件，则count初值为0；mutex的初始为1；w了实现写、读的公平必须设置为0（w是同步信号量，而同步信号量初值一般都是设置为0）

🛩️1.2.3 总结

⛵1.3 哲学家进餐问题

🚁1.3.1 问题描述

🚁1.3.2 问题分析

可以看出，这个问题中只有互斥事件，即：对于五个筷子的任何一个，拿起其中的任何一个都必须互斥的进行。因此必须设置5个互斥信号量，为chopstick[5] = {1,1,1,1,1}。初值为1代表初始时各筷子的数量都为1

🛸1.3.2.1 解决办法

仅当一个哲学家左右两支筷子都可用时才允许他抓起筷子。
（1）代码

（2）解释
其中的（i+1）%5是为了能让i=5时（第五个哲学家），他可以拿到1号的筷子。
①当1号哲学家尝试拿起筷子，执行P(mutex)，再拿起筷子0，接着拿起筷子1，假设此时发生了进程切换，切换到3号哲学家，此时出现一种情况：即使该哲学家旁边的两个筷子都在，但是他还是没有办法拿筷子吃饭。
②当1号哲学家尝试拿起筷子，执行P(mutex)，再拿起筷子0，接着拿起筷子1，执行了V（Mutex）操作，假设此时发生了进程切换，切换到0号哲学家，他先执行P（mutex)，并拿起筷子4，此时他右边的筷子没有，此时出现了一种情况：并不能保证只有哲学家两边的筷子都可用时，哲学家才拿起筷子。

（3）基于以上两种情况，该方案更加合适的说法是：

但是不管怎么说，这个方案都是可行的

🛸1.3.2.2 其他解决办法

🚁1.3.3 总结

⛵1.4 管程

🚠1.4.1 总览

为什么引入管程

我们必须注意到：信号量机制虽然可以有效的解决临界资源的访问问题，但是它的实现方式较为复杂且容易出错，这就给程序的编写造成了很大的困难。引入管程是为了让人们在编写代码时无须关注复杂的PV操作，同时还可以让进程可以同步或互斥的访问某些临界资源（管程可以实现同步、互斥）

🚠1.4.2 管程的定义与特征

1. 定义

2. 特征

3. 可以类比于Java中的class，管程的几个特征都是为了实现对于资源的互斥访问

🚠1.4.3 使用管程解决生产者消费者问题

🛸1.4.3.1 主程序：

🛸1.4.3.2 各进程

较为简单不再赘述

🛸1.4.3.3 总结

🚠1.4.4 Java类似管程的机制

🚠1.4.5 总结

🕮 2 总结

操作系统，如默默守护的守夜者，无声地管理硬件与软件的交流，为计算机创造和谐秩序。

它是无形的引导者，让复杂的任务变得井然有序，为用户提供无忧体验。

操作系统的巧妙设计，让计算机变得更加智能高效，让人与科技之间的交流更加顺畅。

在每一次启动中，它如信任的伙伴，带领我们进入数字世界的奇妙旅程。

渴望挑战操作系统的学习路径和掌握进阶技术？不妨点击下方链接，一同探讨更多操作系统的奇迹吧。我们推出了引领趋势的💻OS专栏：《OS从基础到进阶》 ，旨在深度探索OS的实际应用和创新。🌐🔍