michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-16 14:27:49 +00:00
Code Issues Projects Releases Wiki Activity

Optimize translation.

Browse Source
This commit is contained in:
ic3w1ne
2025-08-11 18:00:22 +08:00
committed by GitHub
parent 7c795ebdd1
commit de8054095c
1 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
blog/content/edition-2/posts/12-async-await/index.zh-CN.md
View File

@@ -48,34 +48,34 @@ translation_contributors = []
### 抢占式多任务处理 ### 抢占式多任务处理
抢占式多任务处理的核心理念在于由操作系统决定何时进行任务切换。 为此，系统利用了每次中断时可重新获得 CPU 控制权这一机制。这使得系统能在有新输入时立即切换任务，例如当鼠标移动或网络数据包到达时。操作系统还可以通过配置硬件定时器在指定时间后发送中断来精确控制每个任务允许运行的时间。 抢占式多任务处理的核心理念在于由操作系统决定何时进行任务切换。 为此，系统利用了每次中断时可重新获得 CPU 控制权这一机制。这使得系统能在有新输入时立即切换任务，例如当鼠标移动或网络数据包到达时。操作系统还可以通过配置硬件定时器，令其在指定时间后发送中断，从而精确控制每个任务允许运行的时间。
下图展示了硬件中断时的任务切换过程: 下图展示了硬件中断时的任务切换过程:
![](regain-control-on-interrupt.svg) ![](regain-control-on-interrupt.svg)
第一行中，CPU 正在执行程序 `A` 的任务 `A1` ，所有其他任务均处于暂停状态。在第二行，一个硬件中断到达 CPU 。如[硬件中断][_Hardware Interrupts_]文章所述，CPU 立即停止执行任务 `A1` 并跳转到中断描述符表(IDT)中定义的中断处理程序。通过这个中断处理程序，操作系统重新获得了 CPU 的控制权，这使得它能够切换到任务 `B1` 而非继续原任务任务 `A1` 。 第一行中，CPU 正在执行程序 `A` 的任务 `A1` ，所有其他任务均处于暂停状态。在第二行，一个硬件中断到达 CPU 。如[硬件中断][_Hardware Interrupts_]文章所述，CPU 立即停止执行任务 `A1` 并跳转到中断描述符表(IDT)中定义的中断处理程序。通过这个中断处理程序，操作系统重新获得了 CPU 的控制权，这使得它能够切换到任务 `B1` 而非继续原任务 `A1` 。
[_Hardware Interrupts_]: @/edition-2/posts/07-hardware-interrupts/index.md [_Hardware Interrupts_]: @/edition-2/posts/07-hardware-interrupts/index.md
#### 保存状态 #### 保存状态
由于任务可能在任意时间点被中断，它们可能正处于某些计算过程中。为了稍后能够恢复他们，操作系统必须备份任务的完整状态，包括其[调用栈][call stack]和所有 CPU 寄存器的值。这一过程被称为[上下文切换][_context switch_]。 任务可能在任意时间点被中断，即使它们可能正处于某些计算过程中。为了稍后能够恢复他们，操作系统必须备份任务的完整状态，包括其[调用栈][call stack]和所有 CPU 寄存器的值。这一过程被称为[上下文切换][_context switch_]。
[call stack]: https://en.wikipedia.org/wiki/Call_stack [call stack]: https://en.wikipedia.org/wiki/Call_stack
[_context switch_]: https://en.wikipedia.org/wiki/Context_switch [_context switch_]: https://en.wikipedia.org/wiki/Context_switch
由于调用栈可能非常大，操作系统通常会为每个线程设置独立的调用栈，而非在每次任务切换时备份调用栈内容。这样一个拥有自己的栈的任务被称为一个 执行线程 [_thread of execution_] 或简称 线程_thread_。通过为每个任务使用独立的栈，在上下文切换时就只需保存寄存器内容（包括程序计数器和栈指针）。这种方法最大限度地减少了上下文切换的性能开销，这一点非常重要，因为上下文切换每秒可能发生多达100次。 由于调用栈可能非常大，操作系统通常会为每个线程设置独立的调用栈，而非在每次任务切换时备份调用栈内容。这样一个拥有自己的栈的任务被称为一个 执行线程 [_thread of execution_] 或简称 线程_thread_。为每个任务使用独立的栈，在上下文切换时就只需保存寄存器内容（包括程序计数器和栈指针）。这种方法最大限度地减少了上下文切换的性能开销，这一点非常重要，因为上下文切换每秒可能发生多达100次。
[_thread of execution_]: https://en.wikipedia.org/wiki/Thread_(computing) [_thread of execution_]: https://en.wikipedia.org/wiki/Thread_(computing)
#### 讨论 #### 讨论
抢占式多任务处理的主要优势在于操作系统能够完全控制任务被允许执行的时间。这种方式可以确保每个任务公平地获得 CPU 时间份额，而无需依赖任务间的协作。这一特性在运行第三方任务或多个用户共享系统时尤为重要。 抢占式多任务处理的主要优势在于操作系统能够完全控制任务允许执行的时间。这种方式可以确保每个任务公平地获得 CPU 时间份额，而无需依赖任务间的协作。这一特性在运行第三方任务或多个用户共享系统时尤为重要。
抢占式多任务处理的缺点在于每个任务都需要独立的堆栈空间。相较于共享栈，使用独立堆栈会导致每个任务占用更多内存，并且通常会限制任务的数量。另一个缺点是操作系统总是需要在每次任务切换时保存完整的 CPU 寄存器状态，即使任务只使用了寄存器的一小部分。 抢占式多任务处理的缺点在于每个任务都需要独立的栈空间。相较于共享栈，使用独立栈会导致每个任务占用更多内存，并且通常会限制任务的数量。另一个缺点是操作系统总是需要在每次任务切换时保存完整的 CPU 寄存器状态，即使任务只使用了寄存器的一小部分。
抢占式多任务处理和线程是操作系统的基本组成部分，因为它们使得运行不受信任的用户空间程序成为可能。我们将在后续文章中详细讨论这些概念。不过本文的重点将放在协作式多任务处理上，因为它也能为我们的内核提供实用功能。 抢占式多任务处理和线程是操作系统的基本组成部分，因为它们使得运行不受信任的用户空间程序成为可能。我们将在后续文章中详细讨论这些概念。不过本文的重点将放在协作式多任务处理上，因为它对于我们的内核来说也足够实用。
### 协作式多任务处理 ### 协作式多任务处理