存储和检索过程控制块答案

【问题标题】：Storing and retrieving process control block存储和检索过程控制块
【发布时间】：2012-04-10 04:54:15
【问题描述】：

当一个进程在执行时，PCB的内容（在内核内存空间？）被加载到CPU寄存器，状态寄存器，内核栈指针、用户栈指针等

当有一个上下文切换到另一个进程时，当前的“上下文”被存储回 PCB 并切换到新的 PCB。

现在当内核想要把这个 PCB 带回“上下文”时，它是如何找到这个现在在内存中的 PCB 的？哪些信息有助于内核找到内存中的 PCB？

【问题讨论】：

标签： operating-system scheduling context-switch process-control

【解决方案1】：

查找处理器可用性是调度的工作，然后只发生上下文切换。一旦内核可用，内核中存储的 PCB 的程序计数器值就会被获取并提供给 CPU 寄存器。我想告诉内核以堆栈方式存储 PCB。

【讨论】：

我认为 PCB 存储在运行队列中，调度程序解析队列并将调度运行的 PCB 上下文放到硬件寄存器中......
@sharatchandra ：您所理解的对于该特定操作系统可能非常正确。 PCB 存储在 OS 定义的数据结构中，所以我们可以说它可以是任何堆栈、队列..!!

【解决方案2】：

PCB：它是一种数据结构，可以是操作系统或用户的一部分。但由于它是几乎所有地方的敏感数据结构，PCB 都是内核数据结构的一部分
PCB 主要存储为每个进程的内核堆栈，位于内核空间中，内核可以访问该堆栈，不受任何用户的影响。
进程切换是调度程序的功能，它是内核模块。有许多调度算法来定义进程切换（长/短期/中期等）
现在调度程序定义下一个将运行的进程而不是内核。内核的作用只是在被调用时提供服务（系统调用/中断/陷阱）。
作为内核模块“scheduler”可以访问所有内核数据结构，因此它定义了进程的顺序（它可以是抢占式或协作式调度程序）。
每个进程都有自己的 PCB，因此活动/运行进程将其 PCB 加载到 CPU 寄存器和其他需要的部分，使用之前存储的 PCB（大部分）在内核堆栈之前。

始终牢记：Kernel 就像一个服务员，服务于所要求的东西，他什么都不知道，像驴子一样做所有事情（尽管是最重要的）。

【讨论】：

【解决方案3】：

我想提供位详细信息（&为了便于理解，考虑每个进程有一个内核线程）。

现在每个内核线程 (kthread) 都有线程上下文 (eip, ebp, esp, pagedir, kstack, kstacksize)。所以，我们都知道线程/进程的生命周期，它会经历像-“Running, Runnable, wait, exit”这样的状态。当线程处于运行状态时，其上下文位于内核数据结构“context_t”中，存储在内核地址空间的某处。并且内核堆栈包含指向该数据结构的指针当线程切换（更专业的说法是 context_switch）发生（原因可能是 - 调度程序 cpu 超时、I/O 操作完成等）时，线程被排入可运行队列内核数据结构中（等待其机会获取 CPU）。

当状态变为“正在运行”时，上下文切换再次发生，现在 context_t 被加载。它具有访问先前存储的数据成员的所有必要指针，现在将使用这些指针从先前的停止状态继续。

所有内核数据结构都存储在内核地址空间（> 0xc0000000）中，线程具有指向这些上下文块的指针。（当线程切换时，新线程指向它的上下文 - 再次上下文切换，下一个线程指向它自己的数据结构。

【讨论】：

【解决方案4】：

操作系统使用Process Table来查找内存中的PCB。

进程表由PID和内存中对应PCB的引用组成。

因此，每当操作系统执行上下文切换时，它都会在相应的 PID 的帮助下查看进程表以查找对 PCB 的引用。

check this image to visualize this concept

【讨论】：