目录
Ⅰ知识点归纳
1.进程的概念
·什么是进程？
早期的计算机一次只能执行一个程序，这种程序完全控制系统，并且访问所有系统资源。到了现代，计算机系统允许加载多个程序到内存，以便于并发执行。这就要求操作系统对各种程序提供更严格的控制和更好地划分和规划。这些 需求引发了进程概念的产生，大白话的说，进程就是正在执行的程序，是现代分时操作系统的工作单元。
操作系统的复杂程度决定它可以为用户带来更好地体验感。虽然它主要它主要关注的是执行用户程序，但是它也要顾及各种系统任务。因此系统会由一组进程组成，操作系统进程和用户进程；操作系统进程执行系统代码，而用户进程执行用户代码。
通过 CPU 的多路复用，所有这些进程可以并发执行。通过在进程之间切换 CPU，操作系统能使计算机更为高效。
·进程的特征
进程是由多程序的并发执行而引出的，它和程序是两个截然不同的概念。进程的基本特征是对比单个程序的顺序执行提出的，也是对进程管理提出的基本要求。
动态性
进程是程序的一次执行，它有着创建、活动、暂停、终止等过程，具有一定的生命周期，是动态地产生、变化和消亡的。动态性是进程最基本的特征。
并发性
指多个进程实体，同存于内存中，能在一段时间内同时运行，并发性是进程的重要特征，同时也是操作系统的重要特征。引入进程的目的就是为了使程序能与其他进程 的程序并发执行，以提高资源利用率。
独立性
指进程实体是一个能独立运行、独立获得资源和独立接受调度的基本单位。凡未建立PCB的程序都不能作为一个独立的单位参与运行。
异步性
由于进程的相互制约，使进程具有执行的间断性，即进程按各自独立的、 不可预知的速度向前推进。异步性会导致执行结果的不可再现性，为此，在操作系统中必须 配置相应的进程同步机制。
结构性
每个进程都配置一个PCB对其进行描述。从结构上看，进程实体是由程序段、数据段和进程控制段三部分组成的。
·程序和进程主要区别
程序是要执行的一组明确的有序操作。另一方面，正在执行的程序的实例是一个进程。
程序的本质是被动的，因为它在执行之前什么也不做，而进程本质上是动态的或活动的，因为它是执行程序和执行特定操作的实例。
程序具有更长的使用寿命，因为它存储在磁盘中，直到它不会被手动删除，而进程的生命周期较短且有限，因为它在进程完成后终止。
在进程中，资源需求要高得多; 它可能需要处理，内存，I / O资源才能成功执行。相反，程序只需要磁盘来存储。
2.多任务处理系统
（1）背景
Linux是一个多用户多任务的操作系统。多用户是指多个用户可以在同一时间使用计算机系统；多任务是指Linux可以同时执行几个任务，它可以在还未执行完一个任务时又执行另一项任务。 操作系统管理多个用户的请求和多个任务。
大多数系统都只有一个CPU和一个主存，但一个系统可能有多个二级存储磁盘和多个输入/输出设备。操作系统管理这些资源并在多个用户间共享资源，当您提出一个请求时，给您造成一种假象，好像系统只被您独自占用。而实际上操作系统监控着一个等待执行的任务队列，这些任务包括用户作业、操作系统任务、邮件和打印作业等。操作系统根据每个任务的优先级为每个任务分配合适的时间片，每个时间片大约都有零点几秒，虽然看起来很短，但实际上已经足够计算机完成成千上万的指令集。每个任务都会被系统运行一段时间，然后挂起，系统转而处理其他任务；过一段时间以后再回来处理这个任务，直到某个任务完成，从任务队列中去除。
Linux系统上所有运行的东西都可以称之为一个进程。每个用户任务、每个系统管理守护进程，都可以称之为进程。Linux用分时管理方法使所有的任务共同分享系统资源。我们讨论进程的时候，不会去关心这些进程究竟是如何分配的，或者是内核如何管理分配时间片的，我们所关心的是如何去控制这些进程，让它们能够很好地为用户服务。
进程的一个比较正式的定义是：在自身的虚拟地址空间运行的一个单独的程序。进程与程序是有区别的，进程不是程序，虽然它由程序产生。程序只是一个静态的指令集合，不占系统的运行资源；而进程是一个随时都可能发生变化的、动态的、使用系统运行资源的程序。而且一个程序可以启动多个进程。
Linux操作系统包括三种不同类型的进程，每种进程都有自己的特点和属性。
交互进程——由一个shell启动的进程。交互进程既可以在前台运行，也可以在后台运行。
批处理进程——这种进程和终端没有联系，是一个进程序列。
监控进程（也称守护进程）——Linux系统启动时启动的进程，并在后台运行。
上述三种进程各有各的作用，使用场合也有所不同。
进程和作业的概念也有区别。一个正在执行的进程称为一个作业，而且作业可以包含一个或多个进程，尤其是当使用了管道和重定向命令。例如“nroff -man ps.1|grep kill|more”这个作业就同时启动了三个进程。
作业控制指的是控制正在运行的进程的行为。比如，用户可以挂起一个进程，等一会儿再继续执行该进程。shell将记录所有启动的进程情况，在每个进程过程中，用户可以任意地挂起进程或重新启动进程。作业控制是许多shell（包括bash和tcsh）的一个特性，使用户能在多个独立作业间进行切换。
一般而言，进程与作业控制相关联时，才被称为作业。
在大多数情况下，用户在同一时间只运行一个作业，即它们最后向shell键入的命令。但是使用作业控制，用户可以同时运行多个作业，并在需要时在这些作业间进行切换。这会有什么用途呢？例如，当用户编辑一个文本文件，并需要中止编辑做其他事情时，利用作业控制，用户可以让编辑器暂时挂起，返回shell提示符开始做其他的事情。其他事情做完以后，用户可以重新启动挂起的编辑器，返回到刚才中止的地方，就象用户从来没有离开编辑器一样。这只是一个例子，作业控制还有许多其他实际的用途。
（2）多任务处理系统代码介绍
虚拟CPU：MT系统在Linux下编译链接为
gcc -m32 t.c ts.s
然后运行a.out。整个MT系统在用户模式下作为Linux进程运行。
3.进程同步
（1）同步
同步亦称直接制约关系，它是指为完成某种任务而建立的两个或多个进程，这些进程因为需要在某些位置上协调它们的工作次序而等待、传递信息所产生的制约关系。进程间的直接制约关系就是源于它们之间的相互合作。
例如，输入进程A通过单缓冲向进程B提供数据。当该缓冲区空时，进程B不能获得所需数据而阻塞，一旦进程A将数据送入缓冲区，进程B被唤醒。反之，当缓冲区满时，进程A被阻塞，仅当进程B取走缓冲数据时，才唤醒进程A。
（2）进程唤醒与睡眠
在 Linux 中，仅等待 CPU 时间的进程称为就绪进程，它们被放置在一个运行队列中，一个就绪进程的状 态标志位为 TASK_RUNNING。一旦一个运行中的进程时间片用完， Linux 内核的调度器会剥夺这个进程对 CPU 的控制权，并且从运行队列中选择一个合适的进程投入运行。
当然，一个进程也可以主动释放 CPU 的控制权。函数 schedule() 是一个调度函数，它可以被一个进程主动调用，从而调度其它进程占用 CPU。一旦这个主动放弃 CPU 的进程被重新调度占用 CPU，那么它将从上次停止执行的位置开始执行，也就是说它将从调用 schedule() 的下一行代码处开始执行。
有时候，进程需要等待直到某个特定的事件发生，例如设备初始化完成、I/O 操作完成或定时器到时等。在这种情况下，进程则必须从运行队列移出，加入到一个等待队列中，这个时候进程就进入了睡眠状态。
Linux 中的进程睡眠状态有两种：一种是可中断的睡眠状态，其状态标志位
TASK_INTERRUPTIBLE；
另一种是不可中断 的睡眠状态，其状态标志位为 TASK_UNINTERRUPTIBLE。可中断的睡眠状态的进程会睡眠直到某个条件变为真，比如说产生一个硬件中断、释放 进程正在等待的系统资源或是传递一个信号都可以是唤醒进程的条件。不可中断睡眠状态与可中断睡眠状态类似，但是它有一个例外，那就是把信号传递到这种睡眠 状态的进程不能改变它的状态，也就是说它不响应信号的唤醒。不可中断睡眠状态一般较少用到，但在一些特定情况下这种状态还是很有用的，比如说：进程必须等 待，不能被中断，直到某个特定的事件发生。
在现代的 Linux 操作系统中，进程一般都是用调用 schedule() 的方法进入睡眠状态的，下面的代码演示了如何让正在运行的进程进入睡眠状态。
sleeping_task = current;
set_current_state(TASK_INTERRUPTIBLE);
schedule();
func1();
/* Rest of the code … */
在第一个语句中，程序存储了一份进程结构指针 sleeping_task，current 是一个宏，它指向正在执行的进程结构。set_current_state() 将该进程的状态从执行状态 TASK_RUNNING 变成睡眠状态TASK_INTERRUPTIBLE。 如果 schedule() 是被一个状态为TASK_RUNNING 的进程调度，那么 schedule() 将调度另外一个进程占用 CPU；如果 schedule() 是被一个状态为 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 的进程调度，那么还有一个附加的步骤将被执行：当前执行的进程在另外一个进程被调度之前会被从运行队列中移出，这将导致正在运行的那个进程进入睡眠，因为 它已经不在运行队列中了。
我们可以使用下面的这个函数将刚才那个进入睡眠的进程唤醒。
wake_up_process(sleeping_task);
在调用了 wake_up_process() 以后，这个睡眠进程的状态会被设置为 TASK_RUNNING，而且调度器会把它加入到运行队列中去。当然，这个进程只有在下次被调度器调度到的时候才能真正地投入运行。
无效唤醒
几乎在所有的情况下，进程都会在检查了某些条件之后，发现条件不满足才进入睡眠。可是有的时候进程却会在 判定条件为真后开始睡眠，如果这样的话进程就会无限期地休眠下去，这就是所谓的无效唤醒问题。在操作系统中，当多个进程都企图对共享数据进行某种处理，而 最后的结果又取决于进程运行的顺序时，就会发生竞争条件，这是操作系统中一个典型的问题，无效唤醒恰恰就是由于竞争条件导致的。
设想有两个进程 A 和 B，A 进程正在处理一个链表，它需要检查这个链表是否为空，如果不空就对链表里面的数据进行一些操作，同时 B 进程也在往这个链表添加节点。当这个链表是空的时候，由于无数据可操作，这时 A 进程就进入睡眠，当 B 进程向链表里面添加了节点之后它就唤醒 A 进程，其代码如下：
A 进程:
1 spin_lock(&list_lock);
2 if(list_empty(&list_head)) {
3 spin_unlock(&list_lock);
4 set_current_state(TASK_INTERRUPTIBLE);
5 schedule();
6 spin_lock(&list_lock);
7 }
8
9 /* Rest of the code … */
10 spin_unlock(&list_lock);
B 进程:
100 spin_lock(&list_lock);
101 list_add_tail(&list_head, new_node);
102 spin_unlock(&list_lock);
103 wake_up_process(processa_task);
这里会出现一个问题，假如当 A 进程执行到第 3 行后第 4 行前的时候，B 进程被另外一个处理器调度投入运行。在这个时间片内，B 进程执行完了它所有的指令，因此它试图唤醒 A 进程，而此时的 A 进程还没有进入睡眠，所以唤醒操作无效。在这之后，A 进程继续执行，它会错误地认为这个时候链表仍然是空的，于是将自己的状态设置为 TASK_INTERRUPTIBLE 然后调用 schedule() 进入睡 眠。由于错过了 B 进程唤醒，它将会无限期的睡眠下去，这就是无效唤醒问题，因为即使链表中有数据需要处理，A 进程也还是睡眠了。
避免无效唤醒
如何避免无效唤醒问题呢？我们发现无效唤醒主要发生在检查条件之后和进程状态被设置为睡眠状态之前， 本来 B 进程的 wake_up_process() 提供了一次将 A 进程状态置为 TASK_RUNNING 的机会，可惜这个时候 A 进程的状态仍然是 TASK_RUNNING，所以 wake_up_process() 将 A 进程状态从睡眠状态转变为运行状态的努力 没有起到预期的作用。要解决这个问题，必须使用一种保障机制使得判断链表为空和设置进程状态为睡眠状态成为一个不可分割的步骤才行，也就是必须消除竞争条 件产生的根源，这样在这之后出现的 wake_up_process () 就可以起到唤醒状态是睡眠状态的进程的作用了。
找到了原因后，重新设计一下 A 进程的代码结构，就可以避免上面例子中的无效唤醒问题了。
A 进程:
1 set_current_state(TASK_INTERRUPTIBLE);
2 spin_lock(&list_lock);
3 if(list_empty(&list_head)) {
4 spin_unlock(&list_lock);
5 schedule();
6 spin_lock(&list_lock);
7 }
8 set_current_state(TASK_RUNNING);
9
10 /* Rest of the code … */
11 spin_unlock(&list_lock);
可以看到，这段代码在测试条件之前就将当前执行进程状态转设置成 TASK_INTERRUPTIBLE 了，并且在链表不为空的情况下又将自己置为 TASK_RUNNING 状态。这样一来如果 B 进程在 A 进程进程检查了链表为空以后调用 wake_up_process()，那么 A 进程的状态就会自动由原来 TASK_INTERRUPTIBLE变成 TASK_RUNNING，此后即使进程又调用了 schedule()，由于它现在的状态是 TASK_RUNNING，所以仍然不会被从运行队列中移出，因而不会错误的进入睡眠，当然也就避免了无效唤醒问题。
Linux 内核的例子
在 Linux 操作系统中，内核的稳定性至关重要，为了避免在 Linux 操作系统内核中出现无效唤醒问题，
Linux 内核在需要进程睡眠的时候应该使用类似如下的操作：
/* ‘q’是我们希望睡眠的等待队列 /
DECLARE_WAITQUEUE(wait,current);
add_wait_queue(q, &wait);
set_current_state(TASK_INTERRUPTIBLE);
/ 或 TASK_INTERRUPTIBLE /
while(!condition) / ‘condition’ 是等待的条件 */
schedule();
set_current_state(TASK_RUNNING);
remove_wait_queue(q, &wait);
上面的操作，使得进程通过下面的一系列步骤安全地将自己加入到一个等待队列中进行睡眠：首先调用 DECLARE_WAITQUEUE () 创建一个等待队列的项，然后调用 add_wait_queue() 把自己加入到等待队列中，并且将进程的状态设置为TASK_INTERRUPTIBLE 或者 TASK_INTERRUPTIBLE。然后循环检查条件是否为真：如果是的话就没有必要睡眠，如果条件不为真，就调用 schedule()。当进程 检查的条件满足后，进程又将自己设置为 TASK_RUNNING 并调用 remove_wait_queue() 将自己移出等待队列。
从上面可以看到，Linux 的内核代码维护者也是在进程检查条件之前就设置进程的状态为睡眠状态，然后才循环检查条件。如果在进程开始睡眠之前条件就已经达成了，那么循环会退出并用 set_current_state() 将自己的状态设置为就绪，这样同样保证了进程不会存在错误的进入睡眠的倾向，当然也就不会导致出现无效唤醒问题。
下面让我们用 linux 内核中的实例来看看 Linux 内核是如何避免无效睡眠的，这段代码出自 Linux2.6 的内核 (linux-2.6.11/kernel/sched.c: 4254):
4253 /* Wait for kthread_stop */
4254 set_current_state(TASK_INTERRUPTIBLE);
4255 while (!kthread_should_stop()) {
4256 schedule();
4257 set_current_state(TASK_INTERRUPTIBLE);
4258 }
4259 __set_current_state(TASK_RUNNING);
4260 return 0;
上面的这些代码属于迁移服务线程 migration_thread，这个线程不断地检查 kthread_should_stop()，
直 到 kthread_should_stop() 返回 1 它才可以退出循环，也就是说只要 kthread_should_stop() 返回 0 该进程就会一直睡 眠。从代码中我们可以看出，检查 kthread_should_stop() 确实是在进程的状态被置为 TASK_INTERRUPTIBLE 后才开始执行 的。因此，如果在条件检查之后但是在 schedule() 之前有其他进程试图唤醒它，那么该进程的唤醒操作不会失效。
Ⅱ实践内容与截图，代码链接
ps 命令是最常用的监控进程的命令，通过此命令可以查看系统中所有运行进程的详细信息。
命令
ps -ef|grep root
截图
