大家好，欢迎来到IT知识分享网。

多重编程的目的是始终使某些进程运行，以最大化CPU利用率。时间共享的目的是在进程之间频繁切换CPU内核，以便用户可以在每个程序运行时与其交互。为了实现这些目标，进程调度器process scheduler选择一个可用进程（可能是从几个可用进程的集合中选择）以在内核上执行程序。每个CPU内核一次可以运行一个进程。

对于单个CPU core的系统，每次不会有操作一个进程被执行，而多核系统可以一次运行多个进程。如果进程比core多，多余的process将不得不等待，直到有一个core闲下来，然后才能被重新调度。在内存中当前进程的数量被称为degree of multiprogramming。

平衡多程序和时间共享的目标还需要考虑进程的一般行为。通常，大多数进程可以描述为I/O绑定或CPU绑定。与I/O绑定的进程花费在执行I/O上的时间多于在计算上花费的时间。相反，与CPU绑定的进程更多使用其时间进行计算，因此很少生成I/O请求。

调度队列

随着进程进入系统，它们对放入一个ready queue就绪队列，进程在其中准备和等待被CPU的core上运行。这个队列一般以链表的形式存储；一个准备队列头包含了列表中第一个PCB（进程控制块）的指针，并且，每个PCB包含了一个指针字段，用以指向准备队列中的下一个PCB。

系统中也含有其他队列。当一个进程被分配给CPU core时，它会执行一会并且最终结束，被打断，或等待特定事件的发生，比如一个I/O请求的完成。假设该进程向磁盘等设备发出I / O请求。由于设备的运行速度明显慢于处理器，因此该过程必须等待I / O可用。等待某个事件（例如I / O完成）发生的进程被放置在等待队列wait queue中，如下图所示：

最常见的进程调度的表示是queueing diagram队列图，如下图所示。有两种类型的队列：ready queue和一组wait queue。圆圈表示为队列服务的资源，箭头代表了系统中的进程的流向。

一个新的进程一开始被放入ready queue。它会一直等待，直到被选中执行，或dispatched被派遣。一旦进程被分配了CPU core，并且运行，那么就会有下面几个事件的其中之一会发生：

• 进程会发出一个I/O请求，然后被放入I/O等待队列
• 进程会创建一个新的子进程，然后被放入等待队列，在那等待子进程结束。
• 由于中断或其时间片到期，可以从内核中强制删除该进程，然后将其放回到ready queue中。

在前两种情形下，进程最后会从等待状态切换到就绪状态，然后再放回ready queue。一个进程会一直持续这个周期，直到它结束。当它结束时，它会从所有的队列中移出，并且释放分配给它的PCB和相关资源。

CPU调度

一个进程在它的生命周期内会在ready queue和各种wait queue里面不断的迁移。CPU调度器CPUscheduler所扮演的角色就是从ready queue里挑选出其中一个进程，然后分配给某个CPU core。CPU调度器必须经常为CPU选择一个新进程。在等待I / O请求之前，与I / O绑定的进程可能仅执行几毫秒。尽管与CPU绑定的进程将需要更长的CPU内核持续时间，但调度器不太可能长时间将内核授予该进程。取而代之的是，它可能被设计为从进程中强行删除CPU并安排另一个进程运行。因此，CPU调度程序每100毫秒至少执行一次，尽管通常更为频繁。

一些操作系统具有调度的中间形式，称为swapping，其关键思想是有时从内存中（以及从CPU的活动竞争中）删除进程可能是有利的，从而降低了内存中进程的数量。之后，该进程可以重新引入内存，并且可以在中断处继续执行。该方案称为swapping，因为可以将进程从内存“swap out”到磁盘，并保存其当前状态，然后再“swap in”入磁盘。从磁盘返回到内存，然后恢复其状态。交换通常仅在内存已过量使用且必须释放时才需要。

上下文切换

中断会导致操作系统从其当前任务更改CPU内核并运行内核例程。这种操作经常在通用系统上发生。发生中断时，系统需要保存CPUcore 上正在运行的进程的当前上下文context，以便它可以在完成处理后恢复该上下文，从本质上讲是挂起该进程然后恢复它。上下文在进程的PCB中表示。它包括CPU寄存器的值，进程状态和内存管理信息。一般来说，我们在内核或用户模式下执行CPU内核当前状态的状态保存state save，然后执行状态还原state restore以恢复操作。

将CPU内核切换到另一个进程需要执行当前进程的状态保存和另一个进程的状态还原。此任务称为上下文切换context switch，如下图所示。发生上下文切换时，内核将旧进程的上下文保存在其PCB中，并加载计划运行的新进程的已保存上下文。上下文切换时间是一个纯开销，因为系统在切换时没有做任何有用的工作。机器之间的切换速度会有所不同，具体取决于内存速度，必须复制的寄存器数以及是否存在特殊指令（例如加载或存储所有寄存器的单个指令）。典型的速度是几微秒

上下文切换时间高度依赖于硬件支持。例如，某些处理器提供多组寄存器。这里的上下文切换仅需要更改指向当前寄存器集的指针。当然，如果活动进程多于寄存器集，则系统会与以前一样，将寄存器数据复制到内存中以及从内存中复制寄存器数据。另外，操作系统越复杂，上下文切换期间必须完成的工作量就越大。高级内存管理技术可能需要在每个上下文中切换额外的数据。例如，当准备使用下一个任务的地址空间时，必须保留当前进程的地址空间。如何保留地址空间以及需要多少工作量取决于操作系统的内存管理方法。

移动系统中的多任务

由于对移动设备的限制，iOS的早期版本不提供用户应用程序的多任务处理；只有一个应用程序在前台运行，而所有其他用户应用程序都被暂停。操作系统任务是多任务的，因为它们是由Apple编写的，且表现得很好。但是，从iOS 4开始，Apple为用户应用程序提供了有限形式的多任务处理，因此允许单个前台应用程序与多个后台应用程序同时运行。（在移动设备上，前台应用程序是当前打开的应用程序并出现在显示屏上。后台应用程序保留在内存中，但不占用显示屏。）iOS 4编程API提供了对多任务的支持，因此允许进程在后台运行而不会被挂起。

但是，它是有限的并且只能使用适用于一些应用程序类型。随着用于移动设备的硬件开始提供更大的内存容量，多个处理核心和更长的电池寿命，iOS的后续版本开始支持功能更丰富的多任务处理，而限制却越来越少。例如，iPad平板电脑上的较大屏幕允许同时运行两个前台应用程序，这种技术称为分屏。

自诞生以来，Android就支持多任务处理，并且对可以在后台运行的应用程序类型不施加任何限制。如果应用程序需要在后台处理，则该应用程序必须使用“服务service”，该服务是代表后台进程运行的单独的应用程序组件。考虑一个音频应用程序：如果应用程序移至后台，则该服务将继续代表后台应用程序将音频数据发送到音频设备驱动程序。实际上，即使后台应用程序被挂起，该服务也将继续运行。服务没有用户界面，并且内存占用很小，因此为移动环境中的多任务提供了一种有效的技术。