有效利用RTOS编程概念支持先进的多线程架构

像MIPS技术公司最新的MIPS32 34K内核这样的多线程架构正吸引着越来越多的关注，这是因为这种架构无需增加太多的芯片资源或功耗即可获得可观的性能增益。这种硬件多线程的关键优势是，它能使用处理器在等待缓冲回填的空闲周期处理其它线程的指令。

使消费类设备应用程序适应多线程环境的代价一般很小，因为大多数程序已经设计为成组的半独立线程。应用程序线程可以分配给处理器中用于处理单线程的专用硬件资源。多个线程可以被同时分配给这样的硬件，并通过共享CPU周期获得最大的效率。

嵌入式运算面临性能障碍

消费类设备和其它嵌入式计算产品的制造商正在增加Wi-Fi、VoIP、蓝牙、视频等各种新的功能，以往功能的增加都要靠大幅提升处理器的时钟速度来实现。台式机的时钟速度目前已经增加到3GHz以上，即使嵌入式设备也接近GHz级。

但在嵌入式应用领域，这种方法很快就失去了可行性，因为大多数设备的运行收到功耗和资源的约束，这些都限制了处理器速度的进一步提高。时钟周期速度的提高将显著地增大功耗，因此对越来越多的嵌入式设备来说高周期速度将不大可行。另外，处理器速度的进一步提高并不能带来相应的性能改善，因为存储器性能的提高跟不上处理器速度提高的步伐，如上图1所示。

处理器速度已经比存储器快很多，在许多应用场合处理器有一半以上的时间在等待缓存行(cache line)回填数据。每当缓存丢失(cache miss)或需要片外存储器访问时，处理器就需要从存储器加载缓存行，将这些字写进缓存，再将旧的缓存行写进存储器，最后恢复线程。

MIPS公司指出，每千条指令接受25次缓存丢失(对多媒体代码来说是一个合理的值)的高端可综合内核如果必须等待50个缓存填充周期，那么将有50%以上的时间处于停止状态。由于处理器速度仍在不断提高，而且比存储器速度的提高幅度大得多，这类问题将变得越来越突出。

图1：处理器速度超过存储器。

多线程技术

多线程技术解决了这一难题，它可以利用处理器原本用于等待存储器访问的空闲时间处理多个并行程序执行线程。当一个线程停下来等待存储器响应时，另外一个线程会马上提交给处理器，从而保持运算资源的充分利用。

值得注意的是，传统处理器不能采用这种方法，因为它需要大量指令周期才能完成线程之间的切换。要想使这种方法顺利工作，多个应用程序线程必须立即有效，并能逐周期运行。

34K处理器是来自面向消费类设备市场的嵌入式处理器主要提供商的首个多线程产品。每个软件线程在线程环境(Thread Context, TC)上执行，一个TC包括一整套通用寄存器和一个程序计数器(program counter)。

每个TC都有自己的指令预取队列，所有队列都完全独立。这意味着内核能在线程间逐周期地进行切换，因此可以避免软件中产生开销。增加更多的TC只需增加很少的额外硅片。TC共享大部分CPU硬件，包括执行单元、ALU和缓存。而且，增加一个TC并不要求CPU拥有另外一个OS软件运行CPU所需的CP0寄存器拷贝。

一组共享CP0寄存器以及与之相关的TC即组成一个虚拟处理单元(VPE)。一个TC运行一个线程，一个VPE管理一个操作系统：如果有两个VPE，那么就可以有两个独立的操作系统，或一个SMP风格的操作系统。带一个TC的VPE看起来就像是传统的MIPS32架构CPU，并且完全兼容MIPS架构规范-其实就是一个完整的虚拟处理器。

34K内核最多可以有9个TC和2个VPE。TC到VPE的联系取决于运行时间。默认情况下所有准备执行的TC都平等分享处理时间，但34K内核也能在某个特殊要求线程可能会"挨饿"的情况下让某个程序影响线程调度，也就是说软件可以控制每个线程的服务质量(QoS)。应用软件与硬件策略管理器(Policy Manager)互动，策略管理器向各个TC分配动态改变的优先级。然后由硬件分发调度器将线程逐个周期地分配给执行单元，从而满足QoS要求。

在像34K这样的多线程环境中，性能可以大大地提高，因为只要一个线程处于等待存储器访问状态，另外一个线程就会占用空闲下来的处理器周期。上图2表明了多线程是如何加快程序执行速度的。当只有线程0运行时，13个处理器周期中只有5个用于指令执行，剩下7个全部在等待缓存行的回填。在这种使用传统处理方式的情况下效率只有38%。

图2：多线程提高了管线效率。

增加线程1就可能使用上述5个用于等待的处理器周期。现在13个处理器周期中用到了10个，效率提高到77%，与最基本情况相比速度加快了一倍。增加线程2后可以完全加载处理