当前位置：文江博客话题详情

空闲进程的代码是什么？

发布于 2024-10-19 16:03:12 字数 108 浏览 3 评论 0原文

当CPU不执行任何操作时，它会运行空闲进程。我听说这个进程会寻找正在队列中等待的程序，以便CPU可以运行它们。这就是它的全部作用吗？它的代码是什么样的？我也有兴趣了解各种操作系统中系统空闲进程的文件名。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

紫﹏色ふ单纯 2024-10-26 16:03:12

该问题包含几个错误的默认假设。以下是一些提示：

它不一定是空闲进程。它在非多线程操作系统上是空闲进程，但在多线程操作系统上则不是。专注于后一种操作系统中的进程是专注于错误的事情。尽管 Microsoft Windows NT 将其称为“空闲进程”，并在其任务管理器中显示它，但重要的机制是空闲线程。空闲进程只是那些线程所属的进程，用于记账。（所有线程必须属于一个进程。）没有文件名。（在许多系统上，进程甚至没有名称。）
并非所有操作系统都有这些空闲进程/线程。在一些较旧的单处理器操作系统上，当没什么可做的，这只是调度程序中的一个特殊情况。这种方法对于多处理器操作系统来说是有问题的（当一个 CPU 在另一个 CPU 想要分派到的进程/线程中空闲时），这就是为什么需要一个始终准备好运行的特殊进程/线程的想法，每个处理器一个系统中，CPU 可以在其自己的私有线程上下文中空闲，这已成为常态。
空闲进程/线程的作用是特定于 CPU 的。空闲进程/线程的重要品质是它必须始终准备好运行。它绝不能阻塞。但它可以为所欲为。然而，通常“无论它喜欢什么”意味着“尽可能少”。规范的空闲线程只是一个无限循环：一条无条件分支指令分支到其自身。多种处理器架构提供了与 x86 hlt 指令等效的指令，其目的一般来说是减少空闲处理器对系统总线的使用（因此，当然，非-空闲处理器可以使用该总线带宽）。因此，在许多架构上，无限循环会重复执行这些指令。一些处理器在执行此类指令时可以在总线上发出其“空闲”状态的信号，外部硬件可以识别这些指令并对其采取行动（例如，通过减慢总线时钟速度并消耗更少的功率）。同样，空闲指令可能会导致处理器本身执行诸如时钟减慢和节能之类的操作。
低级调度不是“线程内”的事情。毕竟，是低级调度程序（通常称为调度程序）决定运行哪个线程首先。它是在线程内运行的中级和（有时，尽管很少）高级调度。例如，中级调度程序可以是每 N 秒唤醒一次并扫描线程表以重新计算动态优先级线程的线程优先级的线程。或者它可能是一个线程，每 N 秒将整个进程段推送到磁盘并再次将它们拉回，具体取决于进程优先级和最近的 CPU 使用情况。（后一种类型在现代分页操作系统中很少见，但它存在于段交换操作系统中。）

The question contains several erroneous tacit assumptions. Here are some pointers:

It's not necessarily an idle process. It's an idle process on non-multithreading operating systems, but not on multithreading ones. Concentrating upon the process in the latter kind of operating system is concentrating upon the wrong thing. Although Microsoft Windows NT calls it an "Idle Process", and displays that in its Task Manager, the important mechanisms are the idle threads. The idle process is simply the process to which those threads belong for the sake of bookkeeping. (All threads must belong to a process.) There's no filename. (Processes don't even have names on many systems.)
Not all operating systems even have these idle processes/threads. On several older uniprocessor operating systems, idling the system when there was nothing to do was simply a special case in the dispatcher. This approach is problematic for multiprocessor operating systems (when one CPU is idling in a process/thread that another CPU wants to dispatch to), and is why the idea of a special process/thread that was always ready to run, one per processor in the system, so that the CPU could idle in its own private thread context, became the norm.
What an idle process/thread does is CPU-specific. The important quality of an idle process/thread is that it must always be ready to run. It must never block. But it can do whatever it likes in doing so. Usually "whatever it likes" means "as little as possible", however. The canonical idle thread is just an infinite loop: an unconditional branch instruction branching to itself. Several processor architectures provide equivalents to the x86 hlt instruction, the intent of which is in general terms to reduce the idling processor's use of the system bus (so that, of course, non-idle processors can use that bus bandwidth). So on many architectures the infinite loop repeatedly executes those instructions. Some processors can signal their "idle" state on the bus when they execute such instructions, which external hardware can recognize and act upon (such as by slowing bus clocks down and consuming less power, for example). Similarly, the idle instructions can cause the processors themselves to do things like clock-slowing and power-saving.
Low-level scheduling is not an "in-thread" thing. After all, it's the low-level scheduler, often called the dispatcher, that determines what thread to even run in the first place. It's medium-level and (sometimes, albeit rarely) high-level scheduling that are run within threads. A medium-level scheduler can be, for example, a thread that wakes up every N seconds and scans the thread table recomputing the thread priorities of dynamic-priority threads. Or it could be a thread that, every N seconds, pushes entire process segments out to disk and pulls them back again, depending from process priority and recent CPU usage. (This latter type is rare on modern paging operating systems, but it existed on segment-swapping operating systems.)