mirror of
https://github.com/Didnelpsun/CS408.git
synced 2026-06-16 23:17:21 +08:00
Update 1-process-management.md
This commit is contained in:
Didnelpsun
@@ -749,7 +749,722 @@ flag[1] = false; // ⑧
|
||||
remainder section;
|
||||
```
|
||||
|
||||
若按照①⑤②⑥③⑦.….的顺序执行，P0和P1将会同时访问临界区。因此，双标志先检查法的主要问题是：违反忙则等待原则。
|
||||
若按照①⑤②⑥③⑦……的顺序执行，P0和P1将会同时访问临界区。因此，双标志先检查法的主要问题是：违反忙则等待原则。
|
||||
|
||||
#### 双标志后检查法
|
||||
|
||||
算法思想：双标志先检查法的改版。前一个算法的问题是先“检查”后“上锁”，但是这两个操作又无法一气呵成，因此导致了两个进程同时进入临界区的问题。因此，人们又想到先“上锁”后“检查”的方法，来避免上述问题。
|
||||
|
||||
```cpp
|
||||
// 表示进入临界区意愿的数组
|
||||
bool flag[2];
|
||||
//刚开始设置为两个进程都不想进入临界区
|
||||
flag [0] = false;
|
||||
flag [1] = false;
|
||||
|
||||
// P0进程
|
||||
flag[0] = true; // ①
|
||||
while (flag[1]); // ②
|
||||
critical section; // ③
|
||||
flag [0] = false; // ④
|
||||
remainder section;
|
||||
|
||||
// P1进程
|
||||
flag[1] = true; // ⑤
|
||||
while (flag[0]); // ⑥
|
||||
critical section; // ⑦
|
||||
flag[1] = false; // ⑧
|
||||
remainder section;
|
||||
```
|
||||
|
||||
若按照①⑤②⑥③⑦……的顺序执行，P0和P1都不能访问临界区。
|
||||
|
||||
因此，双标志后检查法虽然解决了“忙则等待”的问题，但是又违背了“空闲让进”和“有限等待”原则，会因各进程都长期无法访问临界资源而产生“饥饿”现象。
|
||||
|
||||
#### Peterson算法
|
||||
|
||||
算法思想：双标志后检查法中，两个进程都争着想进入临界区，但是谁也不让谁，最后谁都无法进入临界区。Gary L.Peterson想到了一种方法，如果双方都争着想进入临界区，那可以让进程尝试“孔融让梨”，主动让对方先使用临界区。
|
||||
|
||||
```cpp
|
||||
// 表示进入临界区意愿的数组，初始值都是false
|
||||
bool flag[2];
|
||||
// turn表示优先让哪个进程进入临界区
|
||||
int turn = 0;
|
||||
|
||||
// P0进程:
|
||||
flag[0] = true; // ①
|
||||
turn = 1; // ②
|
||||
while (flag[1] && turn==1); //③
|
||||
critical section; // ④
|
||||
flag[0] = false; // ⑤
|
||||
remainder section;
|
||||
|
||||
// P1进程:
|
||||
flag[1] = true; // ⑥ 表示自己想进入临界区
|
||||
turn = 0; // ⑦ 可以优先让对方进入临界区
|
||||
while (flag[0] && turn==0); // ⑧ 对方想进，且最后一次是自己“让梨"，那自己就循环等待
|
||||
critical section; // ⑨
|
||||
flag[1] = false; // ⑩ 访问完临界区，表示自己已经不想访问临界区了
|
||||
remainder section;
|
||||
```
|
||||
|
||||
Peterson算法用软件方法解决了进程互斥问题，遵循了空闲让进、忙则等待、有限等待三个原则,但是依然未遵循让权等待的原则。
|
||||
|
||||
### 进程互斥的硬件实现
|
||||
|
||||
#### 中断屏蔽
|
||||
|
||||
+ 利用“开/关中断指令”实现（与原语的实现思想相同，即在某进程开始访问临界区到结束访问为止都不允许被中断，也就不能发生进程切换，因此也不可能发生两个同时访问临界区的情况）。
|
||||
+ 关中断后即不允许当前进程被中断，也必然不会发生进程切换。
|
||||
+ 直到当前进程访问完临界区，再执行开中断指令，才有可能有别的进程上处理机并访问临界区。
|
||||
+ 优点：简单、高效。
|
||||
+ 缺点：
|
||||
+ 不适用于多处理机。
|
||||
+ 只适用于操作系统内核进程，不适用于用户进程（因为开/关中断指令只能运行在内核态，这组指令如果能让用户随意使用会很危险）。
|
||||
|
||||
#### TS指令
|
||||
|
||||
简称TS指令，也有地方称TestAndSetLock指令，或TSL指令。
|
||||
|
||||
TSL指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成。
|
||||
|
||||
```cpp
|
||||
// 布尔型共享变量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指令，从而导致“忙等”。
|
||||
|
||||
#### Swap指令
|
||||
|
||||
有的地方也叫Exchange指令，或简称XCHG指令。
|
||||
|
||||
Swap指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成。
|
||||
|
||||
```cpp
|
||||
// Swap指令的作用是交换两个变量的值
|
||||
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指令，从而导致“忙等”。
|
||||
|
||||
### 信号量机制
|
||||
|
||||
之前软硬件实现的进程互斥都无法解决让权等待问题，所以Dijkstra提出实现进程互斥和同步的方法——信号量机制。
|
||||
|
||||
#### 信号量机制的基础概念
|
||||
|
||||
+ 用户进程可以通过使用操作系统提供的一对原语来对信号量进行操作，从而很方便的实现了进程互斥、进程同步。
|
||||
+ 信号量其实就是一个变量（可以是一个整数，也可以是更复杂的记录型变量)，可以用一个信号量来表示系统中某种资源的数量，比如：系统中只有一台打印机，就可以设置一个初值为1的信号量。
|
||||
+ 原语是一种特殊的程序段，其执行只能一气呵成，不可被中断。原语是由关中断/开中断指令实现的。软件解决方案的主要问题是由“进入区的各种操作无法一气呵成”，因此如果能把进入区、退出区的操作都用“原语”实现，使这些操作能“一气呵成”就能避免问题。
|
||||
+ 一对原语: wait(S)原语和signal(S)原语，可以把原语理解为我们自己写的函数，函数名分别为wait和 signal，括号里的信号量s其实就是函数调用时传入的一个参数。
|
||||
+ wait、signal原语常简称为P、V操作（来自荷兰语proberen和verhogen)。因此，做题的时候常把wait(S)、signal(S)两个操作分别写为P(S)、V(S)。
|
||||
|
||||
#### 整型信号量
|
||||
|
||||
用一个整数型的变量作为信号量，用来表示系统中某种资源的数量。
|
||||
|
||||
与普通整数变量的区别:对信号量的操作只有三种，即初始化、P操作、V操作。
|
||||
|
||||
```cpp
|
||||
// 加入某计算机系统中有一台打印机，打印机被争用，如果有n台打印机则S初始为为n
|
||||
//初始化整型信号量s，表示当前系统中可用的打印机资源数
|
||||
int S = 1;
|
||||
// wait原语，相当于“进入区”
|
||||
void wait (int &S){
|
||||
while (S <= 0); // 如果资源数不够，就一直循环等待
|
||||
S=S-1; // 如果资源数够，则占用一个资源
|
||||
}
|
||||
|
||||
// signal原语,相当于“退出区”
|
||||
void signal (int &S) {
|
||||
S=S+1; // 使用完资源后，在退出区释放资源
|
||||
}
|
||||
|
||||
// 进程
|
||||
...
|
||||
wait(S); // 进入区，申请资源
|
||||
使用打印机资源... // 临界区，访问资源
|
||||
signal(S); // 退出区，释放资源
|
||||
```
|
||||
|
||||
“检查”和“上锁”一气呵成,避免了并发、异步导致的问题。
|
||||
|
||||
存在的问题：不满足“让权等待”原则，会发生“忙等”。
|
||||
|
||||
#### 记录型信号量
|
||||
|
||||
整型信号量的缺陷是存在“忙等”问题，因此人们又提出了“记录型信号量”，即用记录型数据结构表示的信号量。
|
||||
|
||||
```cpp
|
||||
// 记录型信号量的定义
|
||||
typedef struct {
|
||||
int value;// 剩余资源数
|
||||
struct process *L; // 等待队列
|
||||
}semaphore;
|
||||
|
||||
// 某进程需要使用资源时，通过wait原语申请
|
||||
void wait (semaphore S) {
|
||||
S.value--;
|
||||
// 如果剩余资源数不够,使用block原语使进程从运行态进入阻塞态,并把挂到信号量S的等待队列（即阻塞队列）中。
|
||||
if (S.value < 0) {
|
||||
block(S.L);
|
||||
}
|
||||
}
|
||||
|
||||
// 进程使用完资源后，通过signal原语释放
|
||||
void signal (semaphore S) {
|
||||
S.value++;
|
||||
// 释放资源后，若还有别的进程在等待这种资源，则使用wakeup原语唤醒等德队列中一个进程,该进程从阻塞态变为就绪态
|
||||
if (S.value <= 0) {
|
||||
wakeup(S.L);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
+ 在考研题目中wait(S)、signal(S)也可以记为P(S)、V(S)，这对原语可用于实现系统资源的“申请”和“释放”。
|
||||
+ S.value的初值表示系统中某种资源的数目。
|
||||
+ 对信号量S的一次Р操作意味着进程请求一个单位的该类资源，因此需要执行`S.value--`，表示资源数减1，当S.value <0时表示该类资源已分配完毕，因此进程应调用block原语进行自我阻塞（当前运行的进程从运行态>阻塞态），主动放弃处理机，并插入该类资源的等待队列s.L中。可见，该机制遵循了“让权等待”原则，不会出现“忙等”现象。
|
||||
+ 对信号量S的一次V操作意味着进程释放一个单位的该类资源，因此需要执行`S.value++`，表示资源数加1，若加1后仍是S.value<=0，表示依然有进程在等待该类资源，因此应调用wakeup原语唤醒等待队列中的第一个进程（被唤醒进程从阻塞态→就绪态）。
|
||||
|
||||
#### 信号量机制实现进程互斥
|
||||
|
||||
1. 分析并发进程的关键活动，划定临界区（如对临界资源打印机的访问就应放在临界区）。
|
||||
2. 设置互斥信号量mutex，初值为1。
|
||||
3. 互斥信号量取值为0或1，0代表上锁，1代表释放。
|
||||
4. 在临界区之前执行P(mutex)。
|
||||
5. 在临界区之后执行V(mutex)。
|
||||
6. 注意：对不同的临界资源需要设置不同的互斥信号量。
|
||||
|
||||
```cpp
|
||||
// 信号量机制实现互斥
|
||||
// 要会自己定义记录型信号量,但如果题目中没特别说明,可以把信号量的声明简写成这种形式
|
||||
semaphore mutex=1; // 初始化信号量
|
||||
|
||||
P1(){
|
||||
...
|
||||
P(mutex); // 使用临界资源前需要加锁
|
||||
临界区代码段...
|
||||
V(mutex); // 使用临界资源后需要解锁
|
||||
...
|
||||
}
|
||||
|
||||
P2(){
|
||||
...
|
||||
P(mutex);
|
||||
临界区代码段...
|
||||
V(mutex);
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
#### 信号量机制实现进程同步
|
||||
|
||||
进程同步：要让各并发进程按要求有序地推进。
|
||||
|
||||
1. 分析什么地方需要实现“同步关系”，即必须保证“一前一后”执行的两个操作（或两句代码）。
|
||||
2. 设置同步信号量S，初始为0。
|
||||
3. 同步信号量为整数，释放加一，占用减一。
|
||||
4. 在“前操作”之后执行V(S)。
|
||||
5. 在“后操作”之前执行P(S)。
|
||||
|
||||
```cpp
|
||||
// 信号量机制实现同步
|
||||
// 初始化同步信号量，初始值为0
|
||||
semaphore S=0;
|
||||
P1(){
|
||||
代码1;
|
||||
代码2;
|
||||
V(S);
|
||||
代码3;
|
||||
}
|
||||
P2(){
|
||||
P(S);
|
||||
代码4;
|
||||
代码5;
|
||||
代码6;
|
||||
}
|
||||
```
|
||||
|
||||
+ 若先进行进程P1：
|
||||
+ 执行到V(S)操作，则S++后S=1。
|
||||
+ 之后当进行P2，执行到P(S)操作时，由于S=1，表示有可用资源，会执行S--，S的值变回0，P2进程不会执行block原语，而是继续往下执行代码4。
|
||||
+ 若先进行进程P2：
|
||||
+ 执行到P(S)操作，由于S=0，S--后S=-1，表示此时没有可用资源，因此P操作中会执行block原语，主动请求阻塞。
|
||||
+ 时间片用完后进行进程P1，之后当执行完代码2，继而执行V(S)操作，S++，使S变回0。
|
||||
+ 由于此时有进程在该信号量对应的阻塞队列中，因此会在V操作中执行wakeup原语，唤醒P2进程。这样P2就可以继续执行代码4了。
|
||||
|
||||
#### 信号量机制实现前驱关系
|
||||
|
||||
前驱关系其实是多组同步。
|
||||
|
||||
进程P1中有句代码S1，P2中有句代码S2……P6中有句代码S6。这些代码要求按如下前驱图所示的顺序来执行：
|
||||
|
||||
```terminal
|
||||
|-S4-|
|
||||
|-S2-| |
|
||||
S1-| |-S5-|-S6
|
||||
| |
|
||||
|----S3---|
|
||||
```
|
||||
|
||||
其实每一对前驱关系都是一个进程同步问题（需要保证一前一后的操作）因此：
|
||||
|
||||
1. 要为每一对前驱关系各设置一个同步变量。
|
||||
2. 在“前操作”之后对相应的同步变量执行V操作。
|
||||
3. 在“后操作”之前对相应的同步变量执行Р操作。
|
||||
|
||||
令S1-S2之间信号量为a=0，S1-S3之间的信号量b=0，S2-S4之间信号量为c=0，S2-S5之间信号量为d=0，S4-S6之间信号量为e=0，S5-S6之间信号量为f=0，S3-S6之间信号量为g=0。
|
||||
|
||||
每一条线段靠近根的对当前信号量进行V操作，靠近尾的对当前信号量进行P操作。
|
||||
|
||||
再将每个代码结点旁边的操作聚拢在一起，就是每个进程所应该执行的操作。
|
||||
|
||||
```cpp
|
||||
P1() {
|
||||
...
|
||||
S1;
|
||||
V(a);
|
||||
V(b);
|
||||
...
|
||||
}
|
||||
P2() {
|
||||
...
|
||||
P(a);
|
||||
s2;
|
||||
V(c);
|
||||
V(d);
|
||||
...
|
||||
}
|
||||
P3() {
|
||||
...
|
||||
P(b);
|
||||
S3;
|
||||
V(g);
|
||||
...
|
||||
)
|
||||
P4() {
|
||||
...
|
||||
P(c);
|
||||
S4;
|
||||
V(e);
|
||||
...
|
||||
}
|
||||
P5() {
|
||||
...
|
||||
P(d);
|
||||
S5;
|
||||
V(f);
|
||||
...
|
||||
}
|
||||
P6() {
|
||||
...
|
||||
P(e);
|
||||
P(f);
|
||||
P(g);
|
||||
S6;
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### 进程同步与互斥应用
|
||||
|
||||
PV操作题目分析步骤：
|
||||
|
||||
1. 关系分析。找出题目中描述的各个进程，分析它们之间的同步、互斥关系。
|
||||
2. 整理思路。根据各进程的操作流程确定P、V操作的大致顺序。
|
||||
3. 设置信号量。设置需要的信号量，并根据题目条件确定信号量初值。
|
||||
4. 互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少。
|
||||
|
||||
#### 生产者消费者问题
|
||||
|
||||
+ 系统中有一组生产者进程和一组消费者进程，生产者进程每次生产一个产品放入缓冲区，消费者进程每次从缓冲区中取出一个产品并使用。（这里的“产品”理解为某种数据）
|
||||
+ 生产者、消费者共享一个初始为空、大小为n的缓冲区。
|
||||
+ 只有缓冲区没满时，生产者才能把产品放入缓冲区，否则必须等待。
|
||||
+ 只有缓冲区不空时，消费者才能从中取出产品，否则必须等待。
|
||||
+ 缓冲区是临界资源，各进程必须互斥地访问。
|
||||
|
||||
由缓冲区是临界资源，所以对其访问是互斥关系。
|
||||
|
||||
缓冲区满时，生产者要等待消费者取走产品，所以是同步关系。
|
||||
|
||||
缓冲区空时(即没有产品时），消费者要等待生产者放入产品，所以是同步关系。
|
||||
|
||||
所以分析得到生产者每次要消耗（P）一个空闲缓冲区，并生产（V）一个产品。消费者每次要消耗（P）一个产品，并释放一个空闲缓冲区V。往缓冲区放入/取走产品需要互斥。
|
||||
|
||||
所以设置三个变量，不能合并：
|
||||
|
||||
```cpp
|
||||
semaphore mutex = 1; // 互斥信号量，实现对缓冲区的互斥访问
|
||||
semaphore empty = n; // 同步信号量，表示空闲缓冲区的数量，交给生产者判断
|
||||
semaphore full = 0; // 同步信号量，表示产品的数量，也即非空缓冲区的数量，交给消费者判断
|
||||
|
||||
// 生产者
|
||||
producer() {
|
||||
while(1）{
|
||||
生产一个产品;
|
||||
P(empty); // 消耗一个空闲缓冲区
|
||||
P(mutex); // 上锁缓冲区
|
||||
把产品放入缓冲区;
|
||||
V(mutex); // 解锁缓冲区
|
||||
V(full); // 增加一个产品
|
||||
}
|
||||
}
|
||||
// 消费者
|
||||
consumer() {
|
||||
while (1){
|
||||
P(full); //消耗一个产品（非空缓冲区）
|
||||
P(mutex); // 上锁缓冲区
|
||||
从缓冲区取出一个产品;
|
||||
V(mutex); // 解锁缓冲区
|
||||
V(empty); // 增加一个空闲缓冲区
|
||||
使用产品;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
若调换P操作顺序会怎么样？
|
||||
|
||||
+ 若此时缓冲区内已经放满产品，则empty=o，full=n。
|
||||
+ 则生产者进程执行`P(mutex)`使mutex变为0上锁，再执行`P(empty)`，由于已没有空闲缓冲区，因此生产者被阻塞。
|
||||
+ 由于生产者阻塞，因此切换回消费者进程。消费者进程执行`P(mutex)`，由于mutex为0，即生产者还没释放对临界资源的“锁”，因此消费者也被阻塞。
|
||||
+ 这就造成了生产者等待消费者对产品消费来释放空闲缓冲区，而消费者又等待生产者解锁临界区的情况，生产者和消费者循环等待被对方唤醒，出现“死锁”。
|
||||
+ 同样的，若缓冲区中没有产品，即full=0，empty=n，按先消费者后生产者的顺序执行也会发生死锁。因此，实现互斥的P操作一定要在实现同步的P操作之后。
|
||||
|
||||
而由于V操作是释放不会导致进程阻塞，所以两个V操作可以交换顺序。
|
||||
|
||||
+ 生产者消费者问题是一个互斥、同步的综合问题。
|
||||
+ 对于初学者来说最难的是发现题目中隐含的两对同步关系。
|
||||
+ 有时候是消费者需要等待生产者生产，有时候是生产者要等待消费者消费，这是两个不同的“一前一后问题”，因此也需要设置两个同步信号量。前生产者V后消费者P就是full，前消费者V后生产者者P就是empty。
|
||||
|
||||
#### 多生产者多消费者问题
|
||||
|
||||
桌子上有一只盘子，每次只能向其中放入一个水果。爸爸专向盘子中放苹果，妈妈专向盘子中放橘子，儿子专等着吃盘子中的橘子，女儿专等着吃盘子中的苹果。只有盘子空时，爸爸或妈妈才可向盘子中放一个水果。仅当盘子中有自己需要的水果时，儿子或女儿可以从盘子中取出水果。用PV操作实现上述过程。
|
||||
|
||||
所以盘中是一个大小为1，初始为空的缓冲区。父母分别为两个生产者进程，子女分别为两个消费者进程，其消费的产品类别不同。
|
||||
|
||||
对缓冲区盘子需要互斥使用。
|
||||
|
||||
只有父亲放入苹果女儿才能取出，所以是同步关系。
|
||||
|
||||
只有母亲放入橘子儿子才能取出，所以是同步关系。
|
||||
|
||||
只有盘子空时，父亲或母亲才能放水果，所以也是同步关系。
|
||||
|
||||
所以对于互斥关系设置一个互斥信号量mutex=1，对于苹果设置为apple=0，对于橘子设置为orange=0，对于向拍子放水果设置plate=1（也可以设置为0，后面的处理不同）。
|
||||
|
||||
```cpp
|
||||
// 实现互斥访问盘子（缓冲区）
|
||||
semaphore mutex = 1;
|
||||
// 盘子中有几个苹果
|
||||
semaphore apple = 0;
|
||||
// 盘子中有几个橘子
|
||||
semaphore orange= 0;
|
||||
// 盘子中还可以放多少个水果
|
||||
semaphore plate = 1;
|
||||
|
||||
dad () {
|
||||
while (1）{
|
||||
准备一个苹果;
|
||||
P(plate);
|
||||
P(mutex);
|
||||
把苹果放入盘子;
|
||||
V(mutex);
|
||||
}
|
||||
}
|
||||
mom() {
|
||||
while (1）{
|
||||
准备一个橘子;
|
||||
P(plate);
|
||||
P(mutex);
|
||||
把橘子放入盘子;
|
||||
V(mutex);
|
||||
}
|
||||
}
|
||||
daughter() {
|
||||
while (1）{
|
||||
P(apple);
|
||||
P(mutex);
|
||||
从盘中取出苹果;
|
||||
V(mutex);
|
||||
V(plate);
|
||||
吃掉苹果;
|
||||
}
|
||||
}
|
||||
son(){
|
||||
while (1）{
|
||||
P(orange);
|
||||
P(mutex);
|
||||
从盘中取出橘子;
|
||||
V(mutex);
|
||||
V(plate);
|
||||
吃掉橘子;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
如果不使用互斥量会怎么样？
|
||||
|
||||
+ 刚开始，儿子、女儿进程即使上处理机运行也会被阻塞。如果刚开始是父亲进程先上处理机运行，则父亲P(plate)，可以访问盘子→母亲P(plate)，阻塞等待盘子→父亲放入苹果V(apple)，女儿进程被唤醒，其他进程即使运行也都会阻塞，暂时不可能访问临界资源（盘子）→女儿P(apple)，访问盘子，V(plate)，等待盘子的母亲进程被唤醒→母亲进程访问盘子（其他进程暂时都无法进入临界区）。
|
||||
+ 即使不设置专门的互斥信号量mutex，也不会出现多个进程同时访问盘子的现象。
|
||||
+ 原因在于本题中的缓冲区大小为1，在任何时刻，apple、 orange、 plate三个同步信号量中最多只有一个是1。因此在任何时刻，最多只有一个进程的P操作不会被阻塞，并顺利地进入临界区，此时互斥关系全部变成同步关系。
|
||||
+ 而如果缓冲区大于1，则父母两个可以同时访问临界区，可能导致数据覆盖，所以必须使用互斥信号量。
|
||||
|
||||
+ 解决“多生产者-多消费者问题”的关键在于理清复杂的同步关系。
|
||||
+ 在分析同步问题（一前一后问题）的时候不能从单个进程行为的角度来分析，要把“一前一后”发生的事看做是两种“事件”的前后关系。
|
||||
+ 比如，如果从单个进程行为的角度来考虑的话，我们会有以下结论：
|
||||
+ 如果盘子里装有苹果，那么一定要女儿取走苹果后父亲或母亲才能再放入水果如果盘子里装有橘子，那么一定要儿子取走橘子后父亲或母亲才能再放入水果。
|
||||
+ 这么看是否就意味着要设置四个同步信号量分别实现这四个“一前一后”的关系了?
|
||||
+ 正确的分析方法应该从“事件”的角度来考虑，我们可以把上述四对“进程行为的前后关系”抽象为一对“事件的前后关系”。
|
||||
+ 盘子变空事件→放入水果事件。“盘子变空事件”既可由儿子引发，也可由女儿引发;“放水果事件"既可能是父亲执行，也可能是母亲执行。这样的话，就可以用一个同步信号量解决问题了。
|
||||
|
||||
#### 抽烟者问题
|
||||
|
||||
假设一个系统有三个抽烟者进程和一个供应者进程。每个抽烟者不停地卷烟并抽掉它，但是要卷起并抽掉一支烟，抽烟者需要有三种材料：烟草、纸和胶水。三个抽烟者中，第一个拥有烟草、第二个拥有纸、第三个拥有胶水。供应者进程无限地提供三种材料，供应者每次将两种材料放桌子上，拥有剩下那种材料的抽烟者卷一根烟并抽掉它，并给供应者进程一个信号告诉完成了，供应者就会放另外两种材料再桌上，这个过程一直重复（让三个抽烟者轮流地抽烟）。
|
||||
|
||||
桌子可以抽象为容量为1的缓冲区，要互斥访问。
|
||||
|
||||
组合一：纸+胶水；组合二：烟草+胶水；组合三：烟草+纸。
|
||||
|
||||
同步关系（从事件的角度来分析)：桌上有组合一→第一个抽烟者取走东西；桌上有组合二→第二个抽烟者取走东西；桌上有组合三→第三个抽烟者取走东西；发出完成信号→供应者将下一个组合放到桌上
|
||||
。
|
||||
|
||||
对于同步关系分别设置offer1=0、offer2=0、offer3=0、finish=0。
|
||||
|
||||
```cpp
|
||||
semaphore offer1 = 0; // 桌上组合一的数量
|
||||
semaphore offer2 = 0; // 桌上组合二的数量
|
||||
semaphore offer3 = 0; // 桌上组合三的数量
|
||||
semaphore finish = 0; // 抽烟是否完成
|
||||
int i = 0; // 用于实现三个抽烟者轮流抽烟
|
||||
|
||||
provider() {
|
||||
while(1){
|
||||
// 根据i选择提供材料
|
||||
if(i==0){
|
||||
将组合一放桌上;
|
||||
V(offer1);
|
||||
}
|
||||
else if(i==1){
|
||||
将组合二放桌上;
|
||||
V(offer2);
|
||||
}
|
||||
else if(i==2){
|
||||
将组合三放桌上;
|
||||
V(offer3);
|
||||
}
|
||||
// 向下一个抽烟者提供
|
||||
i=(i+1)%3;
|
||||
// 等待抽烟者反馈
|
||||
P(finish);
|
||||
}
|
||||
}
|
||||
|
||||
smoker1() {
|
||||
while(1）{
|
||||
P(offer1);
|
||||
从桌上拿走组合一;
|
||||
卷烟;
|
||||
抽掉;
|
||||
// 反馈抽烟完成
|
||||
V(finish);
|
||||
}
|
||||
}
|
||||
|
||||
smoker2() {
|
||||
while(1）{
|
||||
P(offer2);
|
||||
从桌上拿走组合而;
|
||||
卷烟;
|
||||
抽掉;
|
||||
// 反馈抽烟完成
|
||||
V(finish);
|
||||
}
|
||||
}
|
||||
|
||||
smoker3() {
|
||||
while(1）{
|
||||
P(offer3);
|
||||
从桌上拿走组合三;
|
||||
卷烟;
|
||||
抽掉;
|
||||
// 反馈抽烟完成
|
||||
V(finish);
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
+ 吸烟者问题可以为我们解决“可以生产多个产品的单生产者”问题提供一个思路。
|
||||
+ 值得吸取的精华是“轮流让各个吸烟者吸烟”必然需要“轮流的在桌上放上组合一、二、三”，注意体会我们是如何用一个整型变量i 实现这个“轮流”过程的。
|
||||
+ 若一个生产者要生产多种产品（或者说会引发多种前驱事件），那么各个V操作应该放在各自对应的“事件”发生之后的位置。
|
||||
|
||||
#### 读者写者问题
|
||||
|
||||
有读者和写者两组并发进程，共享一个文件，当两个或两个以上的读进程同时访问共享数据时不会产生副作用，但若某个写进程和其他进程（读进程或写进程）同时访问共享数据时则可能导致数据不一致的错误。因此要求:
|
||||
|
||||
1. 允许多个读者可以同时对文件执行读操作。
|
||||
2. 只允许一个写者往文件中写信息。
|
||||
3. 任一写者在完成写操作之前不允许其他读者或写者工作写。
|
||||
4. 写者执行写操作前，应让已有的读者和写者全部退出。
|
||||
|
||||
具有两类进程：写进程、读进程。
|
||||
|
||||
互斥关系：写进程-写进程、写进程-读进程。读进程与读进程不存在互斥问题。
|
||||
|
||||
写者进程和任何进程都互斥，设置一个互斥信号量rw，在写者访问共享文件前后分别执行P、V操作。
|
||||
|
||||
读者进程和写者进程也要互斥，因此读者访问共享文件前后也要对rw执行P、V操作。
|
||||
|
||||
如果所有读者进程在访问共享文件之前都执行P(rw)操作，那么会导致各个读进程之间也无法同时访问文件。所以读者写者问题的核心思想――怎么处理该读者共享的问题呢？
|
||||
|
||||
P(rw)和V(rw)其实就是对共享文件的“加锁”和“解锁”。既然各个读进程需要同时访问，而读进程与写进程又必须互斥访问，那么我们可以让第一个访问文件的读进程“加锁”，让最后一个访问完文件的读进程“解锁”。可以设置一个整数变量count来记录当前有几个读进程在访问文件。
|
||||
|
||||
```cpp
|
||||
// 用于实现对文件的互斥访问。表示当前是否有进程在访问共享文件，1代表空闲
|
||||
semaphore rw = 1;
|
||||
// 记录当前有几个读进程在访问文件
|
||||
int count = 0;
|
||||
// 用于保证对count变量的互斥访问
|
||||
semaphore mutex = 1;
|
||||
// 用于实现"写优先"
|
||||
semaphore w=1;
|
||||
|
||||
writer() {
|
||||
while(1){
|
||||
P(w);
|
||||
P(rw); // 写之前”加锁”
|
||||
写文件...
|
||||
V(rw); // 写之后"解锁”
|
||||
}
|
||||
}
|
||||
|
||||
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);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
+ 读者写者问题为我们解决复杂的互斥问题提供了一个参考思路。
|
||||
+ 其核心思想在于设置了一个计数器count用来记录当前正在访问共享文件的读进程数。我们可以用count的值来判断当前进入的进程是否是第一个/最后一个读进程，从而做出不同的处理。
|
||||
+ 另外，对count变量的检查和赋值不能一气呵成导致了一些错误，如果需要实现“一气呵成”，自然应该想到用互斥信号量。
|
||||
+ 最后，还要认真体会我们是如何解决“写进程饥饿”问题的。
|
||||
+ 绝大多数的考研PV操作大题都可以用之前介绍的几种生产者消费者问题的思想来解决，如果遇到更复杂的问题，可以想想能否用读者写者问题的这几个思想来解决。
|
||||
|
||||
#### 哲学家进餐问题
|
||||
|
||||
一张圆桌上坐着5名哲学家，每两个哲学家之间的桌上摆一根筷子，桌子的中间是一碗米饭。哲学家们倾注毕生的精力用于思考和进餐，哲学家在思考时，并不影响他人。只有当哲学家饥饿时，才试图拿起左、右两根筷子（一根一根地拿起）。如果筷子已在他人手上，则需等待。饥饿的哲学家只有同时拿起两根筷子才可以开始进餐，当进餐完毕后，放下筷子继续思考。
|
||||
|
||||
系统中有5个哲学家进程，5位哲学家与左右邻居对其中间筷子的访问是互斥关系。
|
||||
|
||||
这个问题中只有互斥关系，但与之前遇到的问题不同的是，每个哲学家进程需要同时持有两个临界资源才能开始吃饭。如何避免临界资源分配不当造成的死锁现象，是哲学家问题的精髓。
|
||||
|
||||
信号量设置。定义互斥信号量数组
|
||||
chopstick[5]={1,1,1,1,1}用于实现对5个筷子的互斥访问。并对哲学家按0~4编号，哲学家i左边的筷子编号为i，右边的筷子编号为(i+1)%5。
|
||||
|
||||
为了防止死锁：
|
||||
|
||||
1. 可以对哲学家进程施加一些限制条件，比如最多允许四个哲学家同时进餐。这样可以保证至少有一个哲学家是可以拿到左右两只筷子的。
|
||||
2. 要求奇数号哲学家先拿左边的筷子,然后再拿右边的筷子,而偶数号哲学家刚好相反。用这种方法可以保证如果相邻的两个奇偶号哲学家都想吃饭，那么只会有其中一个可以拿起第一只筷子，另一个会直接阻塞。这就避免了占有一支后再等待另一只的情况。
|
||||
3. 仅当一个哲学家左右两支筷子都可用时才允许他抓起筷子。
|
||||
|
||||
```cpp
|
||||
semaphore chopstick[5]={1,1,1,1,1};
|
||||
semaphore mutex = 1; // 互斥地取筷子
|
||||
|
||||
//i号哲学家的进程
|
||||
Pi() {
|
||||
while(1){
|
||||
P(mutex);
|
||||
P(chopstick[i]); // 拿左
|
||||
P(chopstick[(i+1)%5]); // 拿右
|
||||
V(mutex);
|
||||
吃饭...
|
||||
V(chopstick[i]); // 放左
|
||||
V(chopstick[(i+1)%5]); // 放右
|
||||
思考...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
+ 哲学家进餐问题的关键在于解决进程死锁。
|
||||
+ 这些进程之间只存在互斥关系，但是与之前接触到的互斥关系不同的是，每个进程都需要同时持有两个临界资源，因此就有“死锁”问题的隐患。
|
||||
+ 如果在考试中遇到了一个进程需要同时持有多个临界资源的情况，应该参考哲学家问题的思想，分析题中给出的进程之间是否会发生循环等待，是否会发生死锁。
|
||||
|
||||
### 管程
|
||||
|
||||
此前一般使用信号量机制来完成进程互斥同步，但是编写程序困难，易出错。
|
||||
|
||||
#### 管程的概念
|
||||
|
||||
管程是一种特殊的软件模块，有这些部分组成：
|
||||
|
||||
1. 局部于管程的共享数据结构（临界区）说明。
|
||||
2. 对该数据结构进行操作的一组过程。
|
||||
3. 对局部于管程的共享数据设置初始值的语句。
|
||||
4. 管程有一个名字。
|
||||
|
||||
管程的基本特征:
|
||||
|
||||
1. 局部于管程的数据只能被局部于管程的过程所访问。
|
||||
2. 一个进程只有通过调用管程内的过程才能进入管程访问共享数据。（即管程中定义的共享数据结构只能被管程定义的函数所修改）
|
||||
3. 每次仅允许一个进程在管程内执行某个内部过程。（在一个时刻内一个函数只能被一个进程使用）
|
||||
|
||||
Reference in New Issue
Block a user