现代操作系统 进程与线程 操作系统中的进程与线程进程间通信 用户空间与内核空间，进程上下文与中断上下文[总结]

简介

    在传统的操作系统中，进程拥有独立的内存地址空间和一个用于控制的线程。但是，现在的情况更多的情况下要求在同一地址空间下拥有多个线程并发执行。因此线程被引入操作系统。

 

为什么需要线程?

    如果非要说是为什么需要线程，还不如说为什么需要进程中还有其它进程。这些进程中包含的其它迷你进程就是线程。

    线程之所以说是迷你进程，是因为线程和进程有很多相似之处，比如线程和进程的状态都有运行，就绪，阻塞状态。这几种状态理解起来非常简单，当进程所需的资源没有到位时会是阻塞状态，当进程所需的资源到位时但CPU没有到位时是就绪状态，当进程既有所需的资源，又有CPU时，就为运行状态。

    下面我们来看一个具体的例子：

     就拿我写博客的LiveWriter来说，LiveWriter需要监听我打字输入的状态，还需要每隔5分钟对草稿进行自动保存。假设如果这个进程只有一个线程的话，那么当对草稿进行保存时，因为此时需要访问硬盘，而访问硬盘的时间线程是阻塞状态的，这时我的任何输入都会没有响应，这种用户体验是无法接受的，或许我们可以通过键盘或者鼠标的输入去中断保存草稿的过程，但这种方案也并不讨好。而使用多线程，每个线程仅仅需要处理自己那一部分应该完成的任务，而不用去关心和其它线程的冲突。因此简化了编程模型。如图1所示。

    

    图1.两条线程满足各自的功能

   

    更具体的说，线程的好处如下:

    1.在很多程序中，需要多个线程互相同步或互斥的并行完成工作，而将这些工作分解到不同的线程中去无疑简化了编程模型。

    2.因为线程相比进程来说，更加的轻量，所以线程的创建和销毁的代价变得更小。

    3.线程提高了性能，虽然线程宏观上是并行的，但微观上却是串行。从CPU角度线程并无法提升性能，但如果某些线程涉及到等待资源（比如IO，等待输入）时，多线程允许进程中的其它线程继续执行而不是整个进程被阻塞，因此提高了CPU的利用率，从这个角度会提升性能。

    4.在多CPU或多核的情况下，使用线程不仅仅在宏观上并行，在微观上也是并行的。

 

    这里值得注意的是，上面的两个线程如果改成两个进程，那么达不到所要的效果，因为进程有自己独立的内存地址空间，而线程共享进程的内存地址空间。

 

经典线程模型

    另一个看进程和线程的角度是进程模型基于两类不同的概念：资源的组织和执行。在过去没有线程的操作系统中，资源的组织和执行都是由进程完成的。但区分这两者很多时候需要加以区分，这也是为什么需要引入线程。

    进程是用于组织资源的单位，进程将相关的资源组织在一起，这些资源包括：内存地址空间，程序，数据等，将这些以进程的形式组织起来可以使得操作系统管理这些资源更为容易。

    而线程，是每一个进程中执行的一个条线。线程虽然共享进程中的大多数资源，但线程也需要自己的一些资源，比如：用于标识下一条执行指令的程序计数器，一些容纳局部变量的寄存器，以及用于表示执行的历史的栈。

    总而言之：进程是组织资源的最小单位，而线程是安排CPU执行的最小单位。

    其实在一个进程中多个线程并行和在操作系统中多个进程并行非常类似，只是线程共享的是地址空间，而进程共享的是物理内存，打印机，键盘等资源……

    每一个进程和线程所独自占有的资源如表1所示。

      

进程占有的资源	线程占有的资源
地址空间  全局变量  打开的文件  子进程  信号量  账户信息	栈  寄存器  状态  程序计数器

表1.进程和线程所独占的资源

 

    其中，线程可以共享进程独占的资源。

 

    我们常用的术语“多线程”一般指的是在同一个进程中多个线程的并发执行。如图2所示。

    

    图2.没有多线程的系统一个进程只能由一个线程

 

    在多线程的进程中，每个线程轮流使用CPU，因此实际上线程并不是并行的，但从宏观上看，是并行的。

    在多线程模型中，每一个进程初始创建时只有一个线程。这个线程可以通过调用系统的库函数去创建其它线程。线程创建的线程并必须要为其指定地址，因为新的线程自动在创建它的地址空间内工作。虽然一个线程可以创建另一个线程，但通常来讲，线程之间是并列的，并不存在层级关系。

    当一个进程完成其工作后，可以通过调用系统库函数进行销毁。

 

操作系统实现线程的几种模式

     在操作系统中，线程可以实现在用户模式下，也可以实现在内核模式下，也可以两者结合实现。

 

线程实现在用户空间下

    当线程在用户空间下实现时，操作系统对线程的存在一无所知，操作系统只能看到进程，而不能看到线程。所有的线程都是在用户空间实现。在操作系统看来，每一个进程只有一个线程。过去的操作系统大部分是这种实现方式，这种方式的好处之一就是即使操作系统不支持线程，也可以通过库函数来支持线程。

    在这种模式下，每一个进程中都维护着一个线程表来追踪本进程中的线程，这个表中包含表1中每个线程独占的资源，比如栈，寄存器，状态等，如图3所示。

    

    图3.在用户空间中实现线程

 

    这种模式当一个线程完成了其工作或等待需要被阻塞时，其调用系统过程阻塞自身，然后将CPU交由其它线程。

    这种的模式的好处，首先，是在用户空间下进行进程切换的速度要远快于在操作系统内核中实现。其次，在用户空间下实现线程使得程序员可以实现自己的线程调度算法。比如进程可以实现垃圾回收器来回收线程。还有，当线程数量过多时，由于在用户空间维护线程表，不会占用大量的操作系统空间。

    有好处就有坏处，这种模式最致命的缺点也是由于操作系统不知道线程的存在，因此当一个进程中的某一个线程进行系统调用时，比如缺页中断而导致线程阻塞，此时操作系统会阻塞整个进程，即使这个进程中其它线程还在工作。还有一个问题是假如进程中一个线程长时间不释放CPU，因为用户空间并没有时钟中断机制，会导致此进程中的其它线程得不到CPU而持续等待。

 

线程实现在操作系统内核中

     在这种模式下，操作系统知道线程的存在。此时线程表存在操作系统内核中，如图4所示。

     

     图4.线程在操作系统内核中实现

 

    在这种模式下，所有可能阻塞线程的调用都以系统调用(System Call)的方式实现，相比在用户空间下实现线程造成阻塞的运行时调用(System runtime call)成本会高出很多。当一个线程阻塞时，操作系统可以选择将CPU交给同一进程中的其它线程，或是其它进程中的线程，而在用户空间下实现线程时，调度只能在本进程中执行，直到操作系统剥夺了当前进程的CPU。

    因为在内核模式下实现进程的成本更高，一个比较好的做法是另线程回收利用，当一个线程需要被销毁时，仅仅是修改标记位，而不是直接销毁其内容，当一个新的线程需要被创建时，也同样修改被“销毁”的线程其标记位即可。

    这种模式下同样还是有一些弊端，比如接收系统信号的单位是进程，而不是线程，那么由进程中的哪一个线程接收系统信号呢？如果使用了表来记录，那么多个线程注册则通过哪一个线程处理系统信号？

 

混合模式

    还有一种实现方式是将上面两种模式进行混合，用户空间中进程管理自己的线程，操作系统内核中有一部分内核级别的线程，如图5所示。

    

      图5.混合模式

 

     在这种模式下，操作系统只能看到内核线程。用户空间线程基于操作系统线程运行。因此，程序员可以决定使用多少用户空间线程以及操作系统线程，这无疑具有更大的灵活性。而用户空间线程的调度和前面所说的在用户空间下执行实现线程是一样的，同样可以自定义实现。

进程间通信

进程间通信有三方面内容：

• 一个进程如何向另一个进程传送信息
• 保证两个或者多个进程在涉及临界活动时不会彼此影响
• 当存在依赖关系时确定适当次序

竞争条件

两个或多个进程读写某些共享数据，而最后结果取决于进程运行的精确时序，就称为竞争条件。

临界区

如何避免部分条件？实际上凡涉及到共享内存、共享资源的情况都会引发竞争，要避免出现错误，必须对共享资源互斥访问。

我们把对共享内存进行访问的程序片段称为临界区(critical region) 。如果能够进行适当安排，使得进程不可能同时处于临界区，则能够避免竞争条件。尽管这样可以防止竞争条件，但它还不能保证使用共享数据的并发进程能够正确高效地进程操作，对于一个好的解决方案，需要具有以下四个条件：

• 任何两个进程不能同时处于临界区
• 不应对CPU的速度和数目做任何假设
• 临界区外的进程不得阻塞其他进程
• 不得使进程在临界区外无休止等待

忙等待形式的互斥

几种实现互斥的方案

关闭中断

最简单的解决方案是使每个进程进入临界区后先关中断，在离开之前再开中断。中断被关闭后，时钟中断也被屏蔽。CPU只有在发生时钟或其它中断时才会切换，因此关中断后CPU不会切换到其他进程。

此外，把关中断的权力交给用户进程是不明智的，关中断对于操作系统本身是一项很有用的技术，但对于用户进程则不是一种合适通用的互斥机制。

锁变量

设想一个共享（锁）变量，初值为0，当一个进程想进入其临界区时，它首先测试这把锁，如果锁的值为0，则进程将其置为1并进入临界区。若锁已经为1，则进程将一直等待到值变成0。然后，这种做法由于锁本身就是共享内存，依然有可能发生竞争。

严格交替法

如下程序，turn初始为0。

while(true)                    while(true)
{                              {
  while(turn != 0);              while(turn != 1);
  critical_region();             critical_region();
  turn = 1;                      turn = 0;
  noncritical_region();          noncritical_region();
}                              }
进程A                          进程B

持续地检测一个变量直到它具有某一特定值就称为忙等待，忙等待是应该避免的，因为它会浪费CPU时间。一个适用忙等待的锁称为自旋锁。

如上程序，两个进程会严格交替进入临界区，当进程B的noncritical需要很长时间执行的时候，进程A需要等待B完成了才能继续，这违反了一开始介始的条件3，也不是一个很好的方案。

Peterson解决方案

该方法的c语言描述如下：

#define FALSE 0
#define TRUE 1
#define N 2             //进程数
int turn;
int interested[N];
void enter_region(int process)
{
  int other;
  other = 1 - process;
  interested[process] = TRUE;
  turn = process;
  while(turn == process && interested[other] == TRUE);
}
void leave_retion(int process)
{
  interested[process] = FALSE;
}

TSL指令

使用硬件支持方案。

信号量

信息量可以有两种操作：down和up。

对信号量执行down操作是检查其值是否大于0，如果是则减1并继续，如果值为0，则进程将睡眠，而此时down操作并未结束。检查数值、改变数值以及可能发生睡眠操作均作为一个单一的、不可分割的原子操作完成。

up操作递增信号量，如果一个或多个进程在该信息量上睡眠，无法完成一个先前的down操作，则邮系统选择其中的一个并允许其完成它的down操作。于是，对一个有进程在其上睡眠的信号量执行一次up操作后，该信号量仍为0，但是其上睡眠的进程却少了一个。递增信号量的值和唤醒一个进程同样也不可分割。

如果不需要信号量的计数能力，有时候也可以使用信号量的一个简化版本，称互斥。互斥仅仅适用于管理共享资源或一小段代码。互斥是一个可以处于两态之一的变量：解锁和加锁。

消息传递

消息传递这种进程间通信方法使用两条原语send和receive。它们也是系统调用。

用户空间与内核空间，进程上下文与中断上下文[总结]

1、前言

　　最近在学习linux内核方面的知识，经常会看到用户空间与内核空间及进程上下文与中断上下文。看着很熟悉，半天又说不出到底是怎么回事，有什么区别。看书过程经常被感觉欺骗，似懂非懂的感觉，很是不爽，今天好好结合书和网上的资料总结一下，加深理解。

2、用户空间与内核空间　　

　　我们知道现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操心系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核，保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。每个进程可以通过系统调用进入内核，因此，Linux内核由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟空间。空间分配如下图所示：

　　有了用户空间和内核空间，整个linux内部结构可以分为三部分，从最底层到最上层依次是：硬件-->内核空间-->用户空间。如下图所示：

　　需要注意的细节问题：

（1） 内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中。 

（2） Linux使用两级保护机制：0级供内核使用，3级供用户程序使用。

　　内核态与用户态：

（1）当一个任务（进程）执行系统调用而陷入内核代码中执行时，称进程处于内核运行态（内核态）。此时处理器处于特权级最高的（0级）内核代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。

（2）当进程在执行用户自己的代码时，则称其处于用户运行态（用户态）。此时处理器在特权级最低的（3级）用户代码中运行。当正在执行用户程序而突然被中断程序中断时，此时用户程序也可以象征性地称为处于进程的内核态。因为中断处理程序将使用当前进程的内核栈。

参考资料：

http://blog.csdn.net/f22jay/article/details/7925531

http://blog.csdn.net/zhangskd/article/details/6956638

http://blog.chinaunix.net/uid-26838492-id-3162146.html

3、进程上下文与中断上下文

　　我在看《linux内核设计与实现》这本书的第三章进程管理时候，看到进程上下文。书中说当一个程序执行了系统调用或者触发某个异常（软中断），此时就会陷入内核空间，内核此时代表进程执行，并处于进程上下文中。看后还是没有弄清楚，什么是进程上下文，如何上google上面狂搜一把，总结如下：

　　程序在执行过程中通常有用户态和内核态两种状态，CPU对处于内核态根据上下文环境进一步细分，因此有了下面三种状态：

（1）内核态，运行于进程上下文，内核代表进程运行于内核空间。
（2）内核态，运行于中断上下文，内核代表硬件运行于内核空间。
（3）用户态，运行于用户空间。

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

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

　　相对于进程而言，就是进程执行时的环境。具体来说就是各个变量和数据，包括所有的寄存器变量、进程打开的文件、内存信息等。一个进程的上下文可以分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。

（1）用户级上下文: 正文、数据、用户堆栈以及共享存储区；
（2）寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；
（3）系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。

    当发生进程调度时，进行进程切换就是上下文切换(context switch).操作系统必须对上面提到的全部信息进行切换，新调度的进程才能运行。而系统调用进行的模式切换(mode switch)。模式切换与进程切换比较起来，容易很多，而且节省时间，因为模式切换最主要的任务只是切换进程寄存器上下文的切换。

　　硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的 一些变量和参数也要传递给内核，内核通过这些参数进行中断处理。所谓的“ 中断上下文”，其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境（主要是当前被打断执行的进程环境）。中断时，内核不代表任何进程运行，它一般只访问系统空间，而不会访问进程空间，内核在中断上下文中执行时一般不会阻塞。

摘录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.

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

-------------------------------------------

LINUX完全注释中的一段话：

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

参考资料：

http://www.cnblogs.com/hustcat/articles/1505618.html

http://mprc.pku.edu.cn/~zhengyansong/blog/?p=199

http://blog.chinaunix.net/uid-26980210-id-3235544.html