mirror of
https://github.com/CyC2018/Interview-Notebook.git
synced 2026-10-30 18:23:52 +00:00
Update 计算机操作系统 - 进程管理.md
“上下文切换”移到“协程”之前；读者-写者问题的写者优先与公平实现移到进阶篇。
This commit is contained in:
CyC2018
+18
-125
@@ -5,8 +5,8 @@
|
||||
* [1. 进程](#1-进程)
|
||||
* [2. 线程](#2-线程)
|
||||
* [3. 区别](#3-区别)
|
||||
* [4. 协程](#4-协程)
|
||||
* [5. 上下文切换](#5-上下文切换)
|
||||
* [4. 上下文切换](#4-上下文切换)
|
||||
* [5. 协程](#5-协程)
|
||||
* [进程状态的切换](#进程状态的切换)
|
||||
* [进程调度算法](#进程调度算法)
|
||||
* [1. 批处理系统](#1-批处理系统)
|
||||
@@ -74,7 +74,21 @@ QQ 和浏览器是两个进程，浏览器进程里面有很多线程，例如 H
|
||||
- 任务之间需要隔离、一个出错不能拖垮其它任务时用多进程，例如 Chrome 把网页放在单独的渲染进程中，一个网页崩溃不影响浏览器和其它标签页；执行不受信任的代码（例如 Agent 运行模型生成的脚本）也应该放在单独的进程甚至容器中；
|
||||
- 任务之间要频繁共享数据、对创建和切换的开销敏感时用多线程，例如 Web 服务器用线程池处理请求，各线程直接读写同一份本地缓存。
|
||||
|
||||
### 4. 协程
|
||||
### 4. 上下文切换
|
||||
|
||||
上下文切换指的是 CPU 从执行一个线程改为执行另一个线程时，把当前线程的寄存器、程序计数器、栈指针等保存起来，再恢复另一个线程上次保存的值。以下情况会发生上下文切换：
|
||||
|
||||
- 时间片用完，被调度程序换下；
|
||||
- 线程主动阻塞，例如等待 I/O、等待锁、调用 sleep()；
|
||||
- 更高优先级的线程进入就绪状态。
|
||||
|
||||
需要注意的是，系统调用只是从用户态进入内核态，执行完后通常回到同一个线程，不一定发生上下文切换。
|
||||
|
||||
同一进程中的线程切换不需要换地址空间；切换到另一个进程时还要切换页表，TLB 和 CPU 缓存中原来的地址映射和数据对新进程没有用，要重新加载，这部分间接开销通常比保存寄存器更大。x86 的 PCID 可以给 TLB 表项标上所属的地址空间，切换页表时不必清空整个 TLB，没有 PCID 时每次切换页表都会清空 TLB。
|
||||
|
||||
例如把两个执行流固定在同一个 CPU 上，通过两根管道来回传 1 个字节，让它们交替运行，两个线程之间、两个进程之间每次切换都约 1.1 微秒，包含一次 read 或 write 系统调用（Linux 实测，见[附录 A1](#a1-上下文切换)）。数据量很小时两者几乎没有差别，进程切换的额外开销主要在工作集较大时体现出来。线程过多、频繁阻塞时，CPU 会把相当一部分时间花在切换上，可以用 vmstat 的 cs 列或 pidstat -w 观察每秒的切换次数。
|
||||
|
||||
### 5. 协程
|
||||
|
||||
协程（Coroutine）是在用户态实现的轻量级线程，由程序自己调度，而不是由操作系统内核调度。协程在等待 I/O 时主动让出执行权，运行时再把其它协程调度到同一个线程上执行。
|
||||
|
||||
@@ -97,20 +111,6 @@ Java 21 正式引入的虚拟线程（[JEP 444](https://openjdk.org/jeps/444)）
|
||||
|
||||
协程也不能无限创建：每个协程的栈和状态都要占内存，例如把最大堆设为 256 MB 时，启动 100 万个阻塞的虚拟线程会抛出 OutOfMemoryError。协程适合大量任务都在等待 I/O 的场景，例如每个请求都要调用下游接口、查询数据库；CPU 密集的任务没有等待可以让出，开再多协程也只能由少量线程轮流执行，不会更快。
|
||||
|
||||
### 5. 上下文切换
|
||||
|
||||
上下文切换指的是 CPU 从执行一个线程改为执行另一个线程时，把当前线程的寄存器、程序计数器、栈指针等保存起来，再恢复另一个线程上次保存的值。以下情况会发生上下文切换：
|
||||
|
||||
- 时间片用完，被调度程序换下；
|
||||
- 线程主动阻塞，例如等待 I/O、等待锁、调用 sleep()；
|
||||
- 更高优先级的线程进入就绪状态。
|
||||
|
||||
需要注意的是，系统调用只是从用户态进入内核态，执行完后通常回到同一个线程，不一定发生上下文切换。
|
||||
|
||||
同一进程中的线程切换不需要换地址空间；切换到另一个进程时还要切换页表，TLB 和 CPU 缓存中原来的地址映射和数据对新进程没有用，要重新加载，这部分间接开销通常比保存寄存器更大。x86 的 PCID 可以给 TLB 表项标上所属的地址空间，切换页表时不必清空整个 TLB，没有 PCID 时每次切换页表都会清空 TLB。
|
||||
|
||||
例如把两个执行流固定在同一个 CPU 上，通过两根管道来回传 1 个字节，让它们交替运行，两个线程之间、两个进程之间每次切换都约 1.1 微秒，包含一次 read 或 write 系统调用（Linux 实测，见[附录 A1](#a1-上下文切换)）。数据量很小时两者几乎没有差别，进程切换的额外开销主要在工作集较大时体现出来。线程过多、频繁阻塞时，CPU 会把相当一部分时间花在切换上，可以用 vmstat 的 cs 列或 pidstat -w 观察每秒的切换次数。
|
||||
|
||||
## 进程状态的切换
|
||||
|
||||
<div align="center"> <img src="pics/process-states.png" width="720px"/> </div><br>
|
||||
@@ -468,114 +468,7 @@ void writer() {
|
||||
}
|
||||
```
|
||||
|
||||
以下内容由 [@Bandi Yugandhar](https://github.com/yugandharbandi) 提供。
|
||||
|
||||
上面的实现可能导致写者饥饿。下面的实现是写者优先的：写者进入队列之后，只需要等待在它之前进入的读者，不会被之后到达的读者一直阻塞。
|
||||
|
||||
```c
|
||||
int readcount, writecount; //(initial value = 0)
|
||||
semaphore rmutex, wmutex, readLock, resource; //(initial value = 1)
|
||||
|
||||
//READER
|
||||
void reader() {
|
||||
<ENTRY Section>
|
||||
down(&readLock); // reader is trying to enter
|
||||
down(&rmutex); // lock to increase readcount
|
||||
readcount++;
|
||||
if (readcount == 1)
|
||||
down(&resource); //if you are the first reader then lock the resource
|
||||
up(&rmutex); //release for other readers
|
||||
up(&readLock); //Done with trying to access the resource
|
||||
|
||||
<CRITICAL Section>
|
||||
//reading is performed
|
||||
|
||||
<EXIT Section>
|
||||
down(&rmutex); //reserve exit section - avoids race condition with readers
|
||||
readcount--; //indicate you're leaving
|
||||
if (readcount == 0) //checks if you are last reader leaving
|
||||
up(&resource); //if last, you must release the locked resource
|
||||
up(&rmutex); //release exit section for other readers
|
||||
}
|
||||
|
||||
//WRITER
|
||||
void writer() {
|
||||
<ENTRY Section>
|
||||
down(&wmutex); //reserve entry section for writers - avoids race conditions
|
||||
writecount++; //report yourself as a writer entering
|
||||
if (writecount == 1) //checks if you're first writer
|
||||
down(&readLock); //if you're first, then you must lock the readers out. Prevent them from trying to enter CS
|
||||
up(&wmutex); //release entry section
|
||||
|
||||
<CRITICAL Section>
|
||||
down(&resource); //reserve the resource for yourself - prevents other writers from simultaneously editing the shared resource
|
||||
//writing is performed
|
||||
up(&resource); //release file
|
||||
|
||||
<EXIT Section>
|
||||
down(&wmutex); //reserve exit section
|
||||
writecount--; //indicate you're leaving
|
||||
if (writecount == 0) //checks if you're the last writer
|
||||
up(&readLock); //if you're last writer, you must unlock the readers. Allows them to try enter CS for reading
|
||||
up(&wmutex); //release exit section
|
||||
}
|
||||
```
|
||||
|
||||
每个读者都必须先获取 readLock，而只有第一个写者需要获取 readLock，并且直到队列中没有写者时才会释放，因此这种实现可能导致读者饥饿。
|
||||
|
||||
以上两种实现总有一方可能饥饿。下面的实现使用一个先进先出的 serviceQueue 让读者和写者按到达顺序排队，获取共享数据的锁总能在有限时间内完成，因此不会出现饥饿。
|
||||
|
||||
```c
|
||||
int readCount; // init to 0; number of readers currently accessing resource
|
||||
|
||||
// all semaphores initialised to 1
|
||||
Semaphore resourceAccess; // controls access (read/write) to the resource
|
||||
Semaphore readCountAccess; // for syncing changes to shared variable readCount
|
||||
Semaphore serviceQueue; // FAIRNESS: preserves ordering of requests (signaling must be FIFO)
|
||||
|
||||
void writer()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
// <ENTER>
|
||||
down(&resourceAccess); // request exclusive access to resource
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
|
||||
// <WRITE>
|
||||
writeResource(); // writing is performed
|
||||
// </WRITE>
|
||||
|
||||
// <EXIT>
|
||||
up(&resourceAccess); // release resource access for next reader/writer
|
||||
// </EXIT>
|
||||
}
|
||||
|
||||
void reader()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <ENTER>
|
||||
if (readCount == 0) // if there are no readers already reading:
|
||||
down(&resourceAccess); // request resource access for readers (writers blocked)
|
||||
readCount++; // update count of active readers
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
up(&readCountAccess); // release access to readCount
|
||||
|
||||
// <READ>
|
||||
readResource(); // reading is performed
|
||||
// </READ>
|
||||
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <EXIT>
|
||||
readCount--; // update count of active readers
|
||||
if (readCount == 0) // if there are no readers left:
|
||||
up(&resourceAccess); // release resource access for all
|
||||
// </EXIT>
|
||||
up(&readCountAccess); // release access to readCount
|
||||
}
|
||||
|
||||
```
|
||||
这种实现在读者源源不断时可能导致写者饥饿，写者优先和按到达顺序排队的公平实现见[进阶：读者-写者问题](计算机操作系统%20-%20进程管理%20-%20进阶.md#读者-写者问题)。
|
||||
|
||||
## 进程通信
|
||||
|
||||
|
||||
Reference in New Issue
Block a user