一些Linux实时操作系统制造商把中断响应时间和处理器预留作为得到实时Linux的主要方法。但其负面结果是功能环境缩小、服务功能简单，没有实时性的保证。本文分析了RTLinuxPro是如何简易地为用户产生处理器预留和中断控制，以及如何提供一个完整的POSIX RTOS环境来支持它。

    硬实时操作系统一直以来是一个功能单一、非集成化，不受重视的应用领域。另一方面，Linux系统则代表了目前计算机技术当中良好的集成性和普适性。如果把这二者结合起来，那将得到一个功能完善的硬实时操作系统，同时可以把具有web接入的用户的网络功能部分以一种快捷、安全和简单的方式集成到系统当中。
图1：RTLinux技术。

    RTCore就是这样一种能够为RTLinuxPro和RTCoreBSD提供硬实时环境的例子。除了大量的Linux应用接口外，RTCore还提供POSIX环境下硬实时的中断句柄、线程、信号、互斥体(mutexes)、信号量(semaphores)、进程间通信等。

    同类技术中，其它方法的重点是放在对中断响应时间的提高方面。其工作本身是有探索价值的，但取得的结果却很有限，只是在一个特定LINUX版本和硬件体系结构下使中断响应时间得到了改善，仍然没有硬实时方面的保证。同时，采用这些方法的操作系统提供给编程者的服务也十分有限。尽管对于某些基础应用，如频繁的采样和对采样信号的简单快速响应的场合，这些方法是有效的，但多数情况下，却反映出现实中的应用领域根本就不是那么地简单。

特定CPU上的线程引导

    先来看一个实时线程如何将自己装入一个给定的CPU的例子。

----此处放L1----

    这里没有什么新的东西，一个新的线程产生，就像其他任何的POSIX应用一样。区别只是这一行——“pthread_attr_setcpu_np(&attr, 0);”。这句告诉RTCore当新的线程创建的时候，应该把它放到CPU 0中，而且永远不会从CPU中被清除掉。原因在于当一个线程/任务被允许从一个处理器转移到另一个的时候，高速缓存(Cache)的影响会改变实时性能。如果知道了在什么样的CPU上都有哪些线程，那么就可以把这种转移的影响降低到最小，实时性能也会得到显著提高，同时RTOS的调度负荷也降到了最低。

    另外一个比较新的东西是“timespec_add_ns(&next,1000*1000);”，这句给timespec结构体增加了一个毫秒，它是为了方便起见而提供的一个函数(POSIX并没有定义这个函数，所以用户通常要手工规格化一些数据)。如果用户熟悉RTLinux，就不应该对这个函数感到陌生，它已经用了好几年了。RTLinuxPro的用户应该注意到这个函数：rtl_main_wait()，这是一个事件等待句柄，它允许程序暂时挂起直到从用户或者系统接收到一个退出信号。(类似于GUI应用中的事件等待进入函数)。

    上述已经在一个特定的CPU上有了一个线程，并且可以保留该CPU不被普通OS所占用。本文中进行的所有测试都把Linux当作一个普通的OS。

预留处理器

    这个小标题似乎有些模棱两可。本文的题目隐含了处理器预留这个难题的重点，似乎需要深入而详细地讨论，但实际上，代码里只要一行程序就可以了。下面是对前面程序的修改：
...
pthread_attr_setcpu_np(&attr, 0);
pthread_attr_setreserve_np(&attr, 1);
pthread_create(&thread, NULL, thread_code, 0);
...
“pthread_attr_setreserve_np(&attr,
1);”这句设置了线程的一个布尔属性。当在特定处理器上产生了一个线程后，只要该线程存在，GPOS就被禁止在这个处理器上运行。

    实际上也是如此的，一旦这条语句被执行，GPOS就被禁止在处理器上面运行了，只能为创立的线程保留CPU(包括运行在CPU上的其它实时线程)。在有些情况下，允许所有的实时应用程序直接保留在处理器的高速缓存中。由于处理器不用再去RAM中取代码了，所以处理器的性能相对得到了提高。因为GPOS永远不会在Cache中运行，从而不会把实时代码挤出Cache，所以Cache永远都被实时代码占据。(Linux相当庞大，一旦运行起来就会占据很大的Cache空间)。

中断控制

    在上面的代码中，为实时代码保留CPU会对其上的GPOS中断产生负面的影响。由于Linux不在其上运行了，不能接受中断了，所以对于其他设备，如以太网设备这样的硬件就只等通过另外一个CPU为Linux提供信号了。这样就使得保留的处理器不处理任何除了产生实时线程以外的任何中断。

    现在处理器完全在实时线程的控制下了，我们再次把重点放在