单芯片的一致多处理

随着SoC设计元件的出现，如MIPS32 1004K一致处理系统（CPS），单操作系统条件下的片上对称多处理（SMP）已经成为了一种真正的设计选择，而系统架构师也需要了解其优点和局限性。

任务越多，越需要并行

复杂的模块化多任务处理嵌入式软件系统经常表现出“偶然发现的”并发，如图1所示。该系统的总任务可能包括多任务操作，每个操作都有不同的职责，可满足一系列不同的输入需求。如果没有分时操作系统，这些任务中的每个都必须在独立的处理器上运行。在一个分时单处理器（uniprocessor）上，任务可以在交替的时间片段上运行。在一个采用SMP操作系统的多处理器上，任务可以并行地在许多可供使用的处理器上运行。

分布式处理

另一种形式的并行处理已经成为司空见惯的事情，以至于有时甚至不被认为是“并行”的，这就是分布式计算，它的网络客户机/服务器模型是迄今为止最常见的范例。客户机/服务器编程基本上是一种控制流分解的形式。一个程序任务将工作请求连接和发送给系统中的一个或多个专门任务，该系统被指定执行具体的工作，而不是由这个程序任务本身执行所有计算。客户机/服务器编程通常是在LAN和WAN上实现的，SMP SoC内的任务之间的通信也是遵循同一个范例。人们可以利用片上或无效“环回”网络接口通过TCP/IP进行未经修改的客户机/服务器的二进制通信，或者更加有效地利用在存储器中传递数据缓存的本地通信协议。

实际上，此类技术都可以单独使用，或者结合使用，以利用给定应用的基于SMP平台的能力。人们甚至可以构建一种分布式SMP服务器的数据并行阵列，其中每个阵列都可以执行一条控制流的流水线。但是，为了有效地实现这个方案，可能需要非常大的工作量和数据集。

系统软件的支持非常关键

在有些SoC系统中，有可能实现处理器静态物理分解任务的并行性（例如每个输入端口有一个处理器内核），在这样的SoC系统中，把并行的多个任务分配到不同的处理器去处理可以在硬件中完成。这将降低软件开销和占位面积，但是不能提供灵活性。

同样，如果嵌入式应用可以被静态地分解成客户端和服务器端程序，这些程序通过片上互连进行通信，那末系统连接所需的唯一的系统软件就是执行处理器间共用协议的信息传递代码。信息传递协议可提供某些抽象层，可以用来配置更多或更少的处理器来运行共用基础的应用代码，但是对于任何给定的配置，处理器间的负载平衡就像硬件分区一样无声无息。为了实现更加灵活的并行系统编程，需要在一个共享资源的多处理器系统上完成软件分布的任务。

SMP系统的灵活性和适应性

顾名思义，SMP操作系统有一个对系统“对称”的含义。所有处理器都可以发现相同的存储器、相同的I/O器件以及相同的全局操作系统的状态。这将使从一个处理器到另一个处理器的程序移植变得极其简单而有效，如图2所示的简单例子，也将使负载均衡更加容易。无须额外的编程或系统管理，一套采用时间分割的单个CPU上的多任务程序，将同时运行于一个SMP系统的可用CPU之上。如Linux调度程序的SMP调度程序将打开和关闭处理器的程序，一切都以一种公平的方式进行。

作为多处理运行的Linux应用不必为了发挥SMP的并行性而进行修改。在大多数情况下，无须重新进行编译；一个例外则是与非线程安全库静态连接的二进制码。

SMP Linux环境可以提供许多工具，有助于系统设计人员调节可用处理器的任务共享方式。这些任务可以让它们的优先级上升和下降，可以由运行在处理器上的任意子集加以限制。利用适当核的支持，它们可以请求使用不同的实时调度状态。

类UNIX操作系统总是允许应用程序对任务的相对调度优先级进行控制，即使是单处理器分时系统也是这样。随着能够对任务、任务组或系统具体用户的优先级进行操作的更复杂机制的出现，传统上优良的外壳命令（shell command）和系统调用已经增加到Linux当中，这对评判该操作系统的优劣应该是十分必要的。

此外，在多处理器配置方面，所有的Linux任务都有一个参数，定义了哪些处理器组（set of processor）可以对任务进行调度。根据默认，这个参数存在于系统中的整组处理器当中，但是，像优先级一样，这种CPU亲合力可以由taskset外壳命令，或者由显式（explicit system）调用来操作任务的“CPU亲合力”。(责任编辑：admin)