什么是上下文

微信公众号：二进制人生
专注于嵌入式linux开发。

内容整理自网络，主要参考https://blog.csdn.net/wuxing26jiayou/article/details/104883455。红色字体为编者备注。

我们在介绍进程、线程、中断时常常提及上下文的概念，那么什么是上下文。

一、上下文基本概念

进程上下文和中断上下文是操作系统中很重要的两个概念，这两个概念在操作系统课程中不断被提及，是最经常接触、看上去很懂但又说不清楚到底怎么回事。造成这种局面的原因，可能是原来接触到的操作系统课程的教学总停留在一种浅层次的理论层面上，没有深入去研究。

处理器总处于以下状态中的一种：
１、内核态，运行于进程上下文，内核代表进程运行于内核空间；
２、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
３、用户态，运行于用户空间。

其实，除了上面三种状态之外，还有一种就是永远处于内核态的内核线程，内核也有自己的任务需要处理，这类内核线程有一部分完全运行于内核空间，它们也有自己的上下文，所以我们把这种状态归纳为运行于内核线程上下文吧。

通过执行ps命令，可以看到有些进程名以[]括起来，这些就是内核线程，它们负责完成特定的任务，像我们后面会介绍的2号进程或者说内核线程kthreadd。

用户空间的应用程序，通过系统调用(当然触发异常也会)，进入内核空间。这个时候用户空间的进程要传递很多变量、参数的值给内核，内核态运行的时候也要保存用户进程的一些寄存器值、变量等。所谓的“进程上下文”，可以看作是用户进程传递给内核的这些参数以及内核要保存的那一整套的变量和寄存器值和当时的环境等。

硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理。所谓的“中断上下文”，其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境（主要是当前被打断执行的进程环境）。

关于进程上下文LINUX完全注释中的一段话：

当一个进程在执行时,CPU的所有寄存器中的值、进程的状态以及堆栈中的内容被称为该进程的上下文。当内核需要切换到另一个进程时，它需要保存当前进程的所有状态，即保存当前进程的上下文，以便在再次执行该进程时，能够必得到切换时的状态执行下去。在LINUX中，当前进程上下文均保存在进程的任务数据结构中。在发生中断时,内核就在被中断进程的上下文中，在内核态下执行中断服务例程。但同时会保留所有需要用到的资源，以便中断服务结束时能恢复被中断进程的执行。

编者添加的linux原文注释

Process Context

---

One of the most important parts of a process is the executing program code. This code is read in from an executable file and executed within the program’s address space. Normal program execution occurs in user-space. When a program executes a system call or triggers an exception(执行系统调用或者触发异常), it enters kernel-space. At this point, the kernel is said to be “executing on behalf of the process” and is in process context. When in process context, the current macro is valid[7]. Upon exiting the kernel, the process resumes execution in user-space, unless a higher-priority process has become runnable in the interim(过渡期), in which case the scheduler is invoked to select the higher priority process.

Other than process context there is interrupt context, In interrupt context, the system is not running on behalf of a process, but is executing an interrupt handler. There is no process tied to interrupt handlers and consequently no process context.

System calls and exception handlers are well-defined interfaces into the kernel. A process can begin executing in kernel-space only through one of these interfaces – all access to the kernel is through these interfaces.

---

Interrupt Context

When executing an interrupt handler or bottom half(底半部), the kernel is in interrupt context. Recall that process context is the mode of operation the kernel is in while it is executing on behalf of a process – for example, executing a system call or running a kernel thread. In process context, the current macro points to the associated task. Furthermore, because a process is coupled to the kernel in process context(因为进程是以进程上文的形式连接到内核中的), process context can sleep or otherwise invoke the scheduler.


Interrupt context, on the other hand, is not associated with a process. The current macro is not relevant (although it points to the interrupted process). Without a backing process(由于没有进程的背景),interrupt context cannot sleep – how would it ever reschedule?(否则怎么再对它重新调度?) Therefore, you cannot call certain functions from interrupt context. If a function sleeps, you cannot use it from your interrupt handler – this limits the functions that one can call from an interrupt handler.(这是对什么样的函数可以在中断处理程序中使用的限制)

Interrupt context is time critical because the interrupt handler interrupts other code. Code should be quick and simple. Busy looping is discouraged. This is a very important point; always keep in mind that your interrupt handler has interrupted other code (possibly even another interrupt handler on a different line!). Because of this asynchronous nature, it is imperative(必须) that all interrupt handlers be as quick and as simple as possible. As much as possible, work should be pushed out from the interrupt handler and performed in a bottom half, which runs at a more convenient time.


The setup of an interrupt handler’s stacks is a configuration option. Historically, interrupt handlers did not receive(拥有) their own stacks. Instead, they would share the stack of the process that they interrupted[1]. The kernel stack is two pages in size; typically, that is 8KB on 32-bit architectures and 16KB on 64-bit architectures. Because in this setup interrupt handlers share the stack, they must be exceptionally frugal(必须非常节省) with what data they allocate there. Of course, the kernel stack is limited to begin with, so all kernel code should be cautious(中断通常共享被中断进程的内核栈，进程内核栈的大小在32位机上是8K，占据两个页).


A process is always running. When nothing else is schedulable, the idle task runs.
`

内核空间和用户空间是操作系统理论的基础之一，即内核功能模块运行在内核空间，而应用程序运行在用户空间。现代的CPU都具有不同的操作模式，代表不同的级别，不同的级别具有不同的功能，在较低的级别中将禁止某些操作。Linux系统设计时利用了这种硬件特性，使用了两个级别，最高级别和最低级别，内核运行在最高级别（内核态），这个级别可以进行所有操作，而应用程序运行在较低级别（用户态），在这个级别，处理器控制着对硬件的直接访问以及对内存的非授权访问。内核态和用户态有自己的内存映射，即自己的地址空间。

正是有了不同运行状态的划分，才有了上下文的概念。用户空间的应用程序，如果想要请求系统服务，比如操作一个物理设备，或者映射一段设备空间的地址到用户空间，就必须通过系统调用来（操作系统提供给用户空间的接口函数）实现。

通过系统调用，用户空间的应用程序就会进入内核空间，由内核代表该进程运行于内核空间，这就涉及到上下文的切换，用户空间和内核空间具有不同的地址映射，通用或专用的寄存器组，而用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行，所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈中的内容，当内核需要切换到另一个进程时，它需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态，继续执行。

同理，硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境，主要是被中断的进程的环境。

Linux内核工作在进程上下文或者中断上下文。提供系统调用服务的内核代码代表发起系统调用的应用程序运行在进程上下文；另一方面，中断处理程序，异步运行在中断上下文。中断上下文和特定进程无关。

运行在进程上下文的内核代码是可以被抢占的（Linux2.6支持抢占）。但是一个中断上下文，通常都会始终占有CPU（当然中断可以嵌套，但我们一般不这样做），不可以被打断。正因为如此，运行在中断上下文的代码就要受一些限制，不能做下面的事情：

• 1、睡眠或者放弃CPU，这样做的后果是灾难性的，因为内核在进入中断之前会关闭进程调度，一旦睡眠或者放弃CPU，这时内核无法调度别的进程来执行，系统就会死掉；

• 2、尝试获得信号量 如果获得不到信号量，代码就会睡眠，会产生和上面相同的情况；

• 3、执行耗时的任务 中断处理应该尽可能快，因为内核要响应大量服务和请求，中断上下文占用CPU时间太长会严重影响系统功能；

• 4、访问用户空间的虚拟地址 因为中断上下文是和特定进程无关的，它是内核代表硬件运行在内核空间，所以在中断上下文无法访问用户空间的虚拟地址。

关于中断里不能做什么事也是linux驱动开发面试官经常问及的问题。

二、上下文切换与多处理器

于是进程有两个幻觉：一认为自己独享内存；二以为自己独享处理器。我们对于一台机器上的多个进程的幻觉是感觉他们是同时运行。

我们来依次解释下上面的三个幻觉：

关于独享内存不是我们的重点，简单说说。独享内存是指我们每个进程都独享虚拟内存。而虚拟内存地址最终是通过MMU翻译成实际的物理地址。这样做只是为了提供一种逻辑上的连续性，屏蔽内存碎片或是规避因内存有限而扩展到硬盘的各种问题，这样不用考虑实际的的限制从而使应用程序开发变得容易。还有一个值得注意的问题是在这个虚拟内存中如果这个进程是多线程的，那么将共享改空间，除了各自的栈、寄存器和所谓的虚拟处理器（LWP）。这样会导致一个问题就是多个线程的stacksize对进程内存空间的要求呈线性增长，与复杂的多层级递归运算类似，导致stackoverflow。这也是好多语言比如Java的线程模型要求线程创建时指定好stacksize大小的原因。

作者的原话是：“这样会导致一个问题就是多个线程的stacksize对进程栈空间的要求呈线性增长”。我们知道线程必须要有自己独立的栈空间，不然它的局部变量放哪，函数调用时也要进行入栈出栈操作。大家有没有思考过线程的栈位于哪里？大小固定吗？如果固定有多大？实际上线程的栈和进程的栈并没有放在一起，线程的栈在创建线程的时候通过mmap系统调用分配，默认大小是8M，可以由用户通过设置线程属性来设定，当然系统规定了线程栈的最大值，可以通过ulimit命令来查询和设置。由于使用mmap系统调用分配，我们就知道线程的栈位于哪里了（位于进程堆和栈之间的动态映射区）。

关于线程的栈探究，我会另写一篇，这是个十分有趣的问题。

以前是单处理器的机器，后来通过单纯的提高处理器主频，已经无法明显提升系统整体性能。实在没办法了，科学家们就想啊想啊，就相出了多核处理器。这样的话处理线程级的多任务，就可以实现真正的并行了。但问题是处理器的核数远小于需要并行的任务数量。有许多因素都客观限制处理器核数。那要完成多个进程同时执行的幻觉就只能通过来回的轮番执行，快速切换。这就到上下文切换的话题了。

关于上下文切换我仅仅参考linux内核的实现从技术角度来解释：

在linux中一个叫做task_struct结构体代表一个进程，linux调度器会对一个结构体：sched_entity结构体感兴趣并对其进行调度，而它正好嵌入到task_struct中。那具体怎么调度呢？

Linux用红黑树存所有可运行的进程（注意是可运行），使用等待队列wait_queue记录休眠（被阻塞）线程。用一个例子来介绍调度和上下文切换的细节，例如网卡产生一个中断通知有网络数据，执行中的线程阻塞（从执行状态剥离并放入等待队列），然后再到红黑树里面选一个来执行。这个过程的详细过程是：虚拟内存映射和处理器状态均要切换到新线程，前一个线程寄存器、栈信息还有其他状态信息被保存。而新线程的栈信息和寄存器信息被恢复，刚好是反操作。我们把上述过程叫做上下文切换。等到网络数据读取就绪，在等待队列中的线程又被唤醒，接着放入红黑树中，成为可执行态，等待被执行。

多处理器就是一台机器具有多个处理器。它的主流架构叫做对称多处理器（SMP），这些处理器共享内存，共用一个系统，程序可以并行执行在每一个处理器上。拿多核处理器来说，通过一个核心执行一个线程，操作系统通过指令分派让一个核心负责一个程序执行，达到真正意义上的并行。目前的手机尤其是android手机通过添加核心数来提升运行速度。这确实可以得到提高。但是在软件角度还受到几方面限制：一是调度算法针对核心数优化，以充分利用多核优势；二是程序的并行性，如果程序是单线程再多核同时也只能跑在一个上面，其他的却白白浪费；还有就是，增加核心数和处理能力并非成线性关系。

三、 总结

上下文context： 上下文简单说来就是一个环境。

用户空间的应用程序，通过系统调用，进入内核空间。这个时候用户空间的进程要传递 非常多变量、參数的值给内核。内核态执行的时候也要保存用户进程的一些寄存器值、变量等。所谓的“进程上下文”，能够看作是用户进程传递给内核的这些參数以及内核要保存的那一整套的变量和寄存器值和当时的环境等。

相对于进程而言，就是进程运行时的环境。详细来说就是各个变量和数据，包含全部的寄存器变量、进程打开的文件、内存信息等。一个进程的上下文能够分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。

• （1）用户级上下文: 正文、数据、用户堆栈以及共享存储区。
• （2）寄存器上下文
• （3）系统级上下文: 内核用于描述一个进程的数据结构，例如:进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。

本文引入很多的问题，比如中断有栈吗？它的栈在哪里？进程的上下文如何切换？寄存器上下文有哪些寄存器需要保存，是全部吗？发生系统调用时用户空间如何向内核空间传递参数？...