减少优先级倒置问题及基于ORBs中间件的非确定性的软件体系结构
减少优先级倒置问题及基于ORBs中间件的非确定性的软件体系结构
Douglas C. Schmidt
schmidt@uci.edu fsumedh
电子 & 计算机工程系
加利福尼亚大学欧文分校
Sumedh Mungee, Sergio Flores-Gaitan, and Aniruddha Gokhale
{
fsumedh,sergio,gokhale}g@cs.wustl.edu
计算机科学系
华盛顿大学圣路易斯分校
这篇论文于2001年由荷兰出版商Kluwer出版于实时系统刊物的第2期第21卷。
抽象
由于并行分布式应用程序对于实时性的需求，扩展ORB中间件以支持分布式应用程序的呼声越来越高。然而，传统ORB中间件的执行，比如CORBA中间件，对于实时系统对确定性要求，表现出了不适应于此要求的实质性优先级倒置及非确定性。本篇论文为实时系统ORB中间件的研究与设计提供了2种新思路。第1，从以往经验出发，详细举例说明并图解了传统ORB中间件为何无法支持实时系统服务质量的原因。第2，对软件体系结构的连接性及并行性进行了评价，以综合判断实时系统CORBA ORBs中各种减少优先级倒置及非确定性的策略。本篇讨论的观点论证了利用比如CORBA这样的标准面向对象技术的中间件，通过Internet来支持某些特定种类的实时应用程序的可能性。
关键词:实时系统CORBA中间件，面向对象服务质量保障中间件，成效评估
1． 介绍
新一代分布式实时应用程序，比如视频会议，航空电子任务计算和过程控制，需要可以提供完善统计数字及具有确定性质量服务的终端系统以保证反应时间[1]，带宽及可靠性[2]。我们以下所讨论的趋势或倾向将改变分布实时应用程序及终端系统软件开发技术的发展。
集中性增强的中间件和综合架构： 目前在实时系统的研究与开发项目中有一种倾向认为，可以使用基于面向对象的中间件[3]的可重用构件来整合应用程序，从而开发一个实时系统的大致模型架构。中间件的目的即是提高系统效率并减少周期和不同供应商为整合可重用构件而所需做的软件开发工作。
集中性增强的服务质量保障中间件和开发系统：具有完善统计数字及确定性质量服务的开放分布式应用程序构件[4]实现了单一化协作过程，所以，对于实现这一协作过程的远程过程调用及通信技术的需求也逐渐增多。随着内容的多种多样，这些构件必须满足应用程序的功能性及质量保障体系的要求。
集中性增强的标准化和符合杠杆作用原理的用于CTOS嵌入式实时多任务操作系统的硬件及软件：为了对降低培训、移植、维护费用而进行的开发起到杠杆作用，对于CTOS硬件和CTOS操作系统的开发速度也提出了更高的要求。一些有关于CTOS的硬件及软件国际标准目前以质量保障体系标准发行。
其中一个特别值得关注的标准化效果是产生了OMG(对象管理组织)的CORBA(公用对象请求代理（调度）程序体系结构)规范[5]。CORBA是这样的一种中间件，它允许客户调用远程对象方法而无须关心对象的具体位置，使用何种语言编写，运行在怎样的操作系统及硬件平台上，以及相互连接分布式对象通信与网络协议种类[6]。
最近标准CORBA在实时系统[7]及嵌入式系统[8]开发领域又取得了新的进展。一些OMG团体，其中的绝大多数对于实时系统具有浓厚的兴趣(RT SIG)，正在为定义CORBA标准的扩展以支持分布式实时应用程序积极的工作。标准化的实时系统CORBA组件的目标在于，使得实时应用程序可以通过嵌入式系统或多种不同的分布式环境相互作用联系起来，比如Internet。
然而，对分布式实时系统ORB中间件的开发、标准化以及使用杠杆原理配置工作依然显的艰难，尽管上述OMG团体(RT SIG)做出了大量卓有成效的工作。广泛展开、并且标准化的分布式实时系统ORB中间件在CTOS操作系统及相关硬件上运行的成功实例是非常少的。传统的CORBA ORBs一般来说并不适合于对性能非常敏感的分布式实时应用程序，主要原因在于它们[1]缺少服务质量保障的借接口规范，[2]缺少服务质量保障的环境，[3]实时系统的规划特性以及[4]严重的性能低下及[9]不可预见性。
尽管目前一些操作系统、网络协议支持实时系统时序安排，可是并没有给出一种完整的端到端解决方案[10]。而且，关于实时ORB终端系统策略的相关研究也非常少见，且并不深入。例如，服务质量(QoS)研究在网络与操作系统层仅仅刚开始涉及关键性需求及为ORB中间件进行建模设计[11]。
从历史观点来看，高速网络的QoS研究，比如ATM，很大程度上将重点放在了分配虚电路带宽上[12]。同样地，实时操作系统的研究则将精力放在了避免
多线程应用程序的同步状态下优先级倒置和分派机制上[13]。所以，一个非常重要的开放性研究课题，是确定怎样最好地将从网络层和操作系统层来的QoS结果部署到许多使用ORB中间件的实时应用程序开发者所熟悉的编程模型上来。
本篇论文以如下方式组织：第2部分勾勒了影响实时ORB终端系统性能及可预见性的基本因素；第3部分描述实时ORB核心的软件体系，焦点集中在可选择性的ORB核心通信与连接软件体系；第4部分代表了一种经验性的观点，系统地测试各种可选择的ORB核心体系的4种不同时期的CORBA执行方法：CORBAplus, miniCOOL, MT-Orbix和TAO；第5部分比较了与我们的研究成果与相关的实践工作；第6部分主要是结束的评论部分，为求尽善尽美，附录A提供了一套完整的CORBA参考样式。
2.影响实时ORB终端系统性能的因素
满足Qos性能需求下一代分布式应用程序所需要的不仅仅是定义一套接口定义语言(IDL)或是在操作系统中加入一套抢先式实时系统时序控制体系。它还需要一套二维网格状完整的ORB终端系统体系，在整个分布式系统的多层次上来发送有QoS担保的端到端信息[10]。在一个ORB终端系统中，关键的层次包括网络适配器，操作系统输入/输出子系统，通信协议，ORB中间件，以及图1所指出的高层次服务。
本篇论文的焦点在于适合于实时ORB核心的软件体系架构。ORB核心是CORBA参考模型中管理传输连接，发送客户请求到对象适配器，并且返回回应(如果需要)到客户端的组件。并且它也执行端点(多路)信号分离器传输和应用程序所使用的通信体系架构。图1举例说明了ORB核心如何与其他ORB组见整合为一体。附录A更加具体地描述了标准CORBA组件。
更加完全的，2.1节简要地叙述了基于ORB终端系统的性能原始资料。2.2节描述了影响实时ORB终端系统的可预见性和利用率的优先级倒置和非确定因素的关键原因。在总体概括后，第3节对可选择的ORB核心通信与连接体系进行了深入探讨。
2．1基于ORB终端系统性能的原始资料
我们的测量CORBA实现的吞吐量和延迟的经验[14, 15, 16, 17]表明在实时ORB端系统中的性能开销来源于以下组件的低效：
1．网络连接和网络适配卡：这些组件处理异构网络的连接和带宽，它们能极大地增加延迟和引起性能的变化。网络适配卡的低效设计会引起排队延迟和丢失数据报[18]，对于某些类型的实时系统而言，这些是难以接受的。
2．通信协议的实现和同I/O子系统和网络适配卡的集成：低效的协议实现和同I/O子系统的不适当的集成会逆向影响端系统的性能。引起无效性的特定因素包括由流控制、阻塞控制、重发策略、和连接管理引起的协议开销。同样，缺乏同I/O子系统的适当集成会产生过量的数据拷贝、碎片、重装、上下文切换、同步、检查和计算、多路转发、编组和解组等开销[19]。
3．ORB传输协议的实现：ORB传输协议的低效实现，如IIOP协议[5]和SFP[20]协议，会引起极大的性能开销和优先级颠倒。要对这些颠倒负责的特别因素包括在ORB协议实现中的不适当的连接管理策略、低效的端系统资源共享、和过多的同步开销。
4．ORB核心的实现和同操作系统服务的集成：一个设计不当的ORB核心会产生过多的内存访问、高速缓存命中率低、堆的分配/去分配、和上下文切换[21]。反过来，这些因素会增加延迟和抖动，这对于具有确定的实时需求的分布式应用来说是难以接受的。引起低效的特定ORB核心因素包括：数据拷贝、分割/重装、上下文切换、同步、检查和、socket多路转发、定时器处理、请求多路转发、编组/解组、分帧、错误检查、连接和并发性结构。许多这些低效性与‘2’类似，因为它们都发生在用户级而不是核心级（注：相对于操作系统而言），然而，ORB实现常常能更方便地处理它们。
图2标示出了以上叙述的影响ORB系统性能的多方面因素所在以及如何真正在实用中进行最优化工作以减少优先级倒置和不确定性的关键原因。在页低，我们描述了ORB终端系统中应主要对优先级倒置和非确定因素负责的组件。
2．2 ORB终端系统用中导致优先级倒置与非确定因素的原因
对于控制实时操作系统和ORB中间件的程序执行时间来说，将优先级倒置和非确定因素影响最小化是非常重要的。在ORB端系统中，优先级颠倒和不确定性通常来源于在多个线程或进程之间共用的资源（注：高优先级线程可能因竞争不到资源，而必须等待低优先级的线程释放资源）。常见的可共用ORB端系统中资源包括供一个CORBA IIOP协议引擎使用的[1]TCP连接，用来通过客户和服务器的传输端点传输请求的线程[2]，进程范围的动态内存管理器[3]，以及内部的ORB数据结构[4]，如传输端点的连接表和客户请求的多路分解的映射。以下描述在常规ORB端系统中优先级颠倒和不确定性的关键来源。
2．2．1 操作系统I/0子系统
一个I/O子系统是操作系统中的一个组件，负责居中协调应用程序和ORB对低层的网络资源和操作系统资源的访问（注：应用程序和ORB是一方，操作系统和网络是另一方，I/O子系统是居中协调者），这些资源包括设备驱动程序、协议栈、CPUs等。在创建一个高性能、实时I/O子系统中的关键挑战在于[1]要最小化上下文切换（如挂起一个线程转去执行另一个线程引起的上下文切换）和同步的开销，[2]要实施QoS保证，而同时要最小化优先级颠倒和不确定性。
当一个正在执行的线程自愿或不自愿地放弃正在执行它的CPU时，就会触发（发生）一个上下文切换，依赖于下层的操作系统和硬件平台，一个上下文切换可能需要执行数百条指令来刷新寄存器窗口、刷新内存高速缓存、刷新指令流水线、和刷新转换旁看的缓冲区。同步的开销来自于封锁机制，这些机制串行化对共享资源的访问，典型的共享资源如在操作系统和ORB中I/O缓冲区、消息队列、协议连接记录、以及在协议处理期间使用的多路转发映射。
诸如Solaris 和 Windows NT等通用操作系统的I/O子系统不执行抢先的、按优先级的协议处理。因此，较低优先级的数据报的协议处理是不会由于较高优先级的数据报的到达而被延迟的，而是进入的数据报按它们到达的顺序被处理，不是按它们的优先级被处理。
[22]检查了在I/O子系统中引起的关键优先级颠倒问题，并描述了TAO的实时I/O子系统如何通过协同调度用户级和核心级实时线程避免许多形式的优先级颠倒问题。有趣的是，在第四节中的结果表明，在ORB端系统中的多数开销、优先级颠倒、和非确定性并不起源于在I/O子系统中协议实现，而是来自ORB核心的软件结构。
2．2 ORB核心
一个ORB的核心是CORBA中的一个组件，它实现通用ORB间协议（GIOP），该协议定义了（可以是异构的）ORB间互操作的格式。ORB核心建立连接和实现处理GIOP请求的并发性结构。以下的讨论描述了在通常的ORB核心实现中的优先级颠倒和非确定性的根源。
连接结构：ORB核心的连接结构，定义了请求如何被映射到网络连接，对ORB实时系统的表现起到主要影响。因此，对于实时ORB的开发人员的一个关键挑战是要选择一个能有效地利用一个ORB端系统的传输机制的连接结构。以下讨论描述了由通常ORB核心的连接机制展现的优先级颠倒和非确定性的根源：
l 动态连接管理：通常的ORB以响应客户请求的方式动态地建立连接。然而，动态连接管理可引起极大的运行时的开销和优先级颠倒。例如，一个高优先级的客户可能要等待一个低优先级客户完成连接建立，而且，建立连接所需的时间可能变化很大，范围从微秒级到毫秒级，取决于端系统的负载和网络的拥挤程度。
连接建立的开销是很难定界限的，例如，如果ORB需要动态地在一个客户和一个服务器之间建立连接，是难以提供一个最坏情况下执行时间的合理保证的，因为这一时间必须包含（常常是变化的）连接建立时间。而且，连接建立常常会发生在通常的端对端操作系统QoS协议实施机制的范围之外，例如重发计时器[25]。为了支持应用的确定性的实时QoS需求，因此ORB端系统常常必须事先预分配连接。
l 连接的多路复用：通常ORB核心常常由一个服务进程内的伺服程序的所有对象引用共用一个单一的多路复用的TCP连接，见图3。
连接多路复用的目的是要最小化每个服务器打开的连接的数量，例如要改进服务器在TCP上的可扩放性。然而，连接的多路复用回产生极大的数据报级的优先级颠倒和同步的开销，见后面的章节。
并发性的结构：ORB核心的并发性的结构（它定义如何将请求映射到线程）也对它的实时行为有极大的影响。实时ORB的开发人员面临的另一个关键挑战是要选择能有效地在一个或多个线程中共享一个ORB端系统和它的应用操作的总的处理能力的一个并发性体系结构。以下描述由通常的ORB核心的并发性机制展示的优先级颠倒和非确定性的关键根源：
l 双向的操作响应处理：在客户方，双向操作的通常ORB核心的并发性结构可能会引起极大的优先级颠倒。例如，使用连接多路复用的多线程ORB核心在正在等待一个服务器的副本的低优先级线程封锁住正在等待同一服务器的副本的较高优先级的线程时，就会引起优先级颠倒。
l 线程池：在服务器方，ORB核心的并发性结构常常使用线程池[26]来选择一个处理一个进入的请求的线程。然而，通常的ORB不提供使实时应用能指派这一池中线程的优先级的程序设计接口。因此，池中一个线程的优先级常常不适合于将最终执行该请求的伺服程序的优先级。一个设计不当的ORB核心会增加优先级颠倒和不确定性的可能性和持续时间[27]。
2．2．3 对象适配器
对象适配器是CORBA体系中负责分接请求，以服务于响应对应请求的操作的组件。一个标准的适应于GIOP的客户请求包含了其对象与操作的身份识别。每个对象被一个8个字节的对象标志所识别，当然对象标志是唯一的。每个操作被表示为一组字符串。如图4所示，ORB终端系统必须负起以下分接的任务。
步骤1与2：从网络物理层开始，通过数据链路层，和传输层到应用层分界（例如:接口套），这里数据在一个服务器进程里被传输给ORB核心，这个过程中操作系统的协议栈分时地分接客户的请求信息
步骤3与4：ORB核心在客户对象标识上使用地址信息来定位适当的POA接口和服务。POA接口被分层次的组织。因此，定位指定服务的POA可以使我们专注于嵌套的POA分层中的一系列分接步骤。
步骤5与6：POA接口使用方法名称来定位适当的IDL框架，这个框架对方法参数的请求缓冲进行反编列并执行内核线程upcall来对开发者工作进行补充编码，以执行对象的方法。
如图4所示的传统深层的ORB终端系统总体来说并不适合对性能要求较高的实时系统，原因如下所述[28]：
逐渐减少的效率：在ORB终端系统处理过程中，分层的分接产生了额外的必须以客户需求递增被搜索的内部表格，因而降低了性能。在所有这些层次中分接客户请求是非常昂贵，尤其是当很大一部分的操作同时集中出现在一个IDL接口中时，或者说很多的服务被一个对象适配器所管理时。
逐渐增长的优先级倒置与非确定性： 由于对于低层的设备驱动和ORB终端的I/O子系统协议栈来说，服务层Qos信息是无法取得的，所以分层解复用会导致优先级的倒置。因此，一个对象适配器也许会根据他们获取的FIFO次序解复用数据包。FIFO解复用将会导致更高优先级的信息包却要在不确定的时间里等待低优先级的信息包被解复用和分派出去。
传统的CORBA执行方式将导致严重的提前解复用问题.举例来说, [15, 17]表现出传统的ORBs有17%的服务器时间来处理解复用请求,除非提前问题能够被降低并且解复用能够表现出可预见性。对于实时系统,ORBs无法作出统一,且可升级的Qos保证。
[14]现在可选择性的ORB解复用技术描述了Tao实时对象适配器如何提供最理想的解复用策略来持续稳定的执行。Tao使用的解复用策略采用可以根据Tao适配器来移除不必要层次的未分层解复用来避免优先级倒置。
3 选择性的ORB核心通信及连接体系架构
在这一部分描述了相当数量的普通ORB核心通信和连接体系架构。每种体系可以被一种或多种的用于商用及研究的CORBA所执行。下面，我们从质量上评价一下每种体系是如何管理ORB终端组件的集合处理能力和应用程序操作。第4部分从数量上举例说明了实际应用中这些可选的表现有多么高效率并具有可预见性。
3．1 可选择的ORB核心连接体系
有二个构造一个ORB核心的连接结构的通用策略：多路复用和非多路复用。集中于客户端连接架构，我们对下面的各种各样的设计选择情况分别作出描述和评价。
3．1．1 分解体系架构
大多数传统的ORBs 分解所有从与一个进程进行的连接中发散出的所有客户端请求。这一多路复用的连接结构通过最小化被打开通向每个服务器的TCP连接的数量被用来构建可扩放的ORBs。然而当使用多路复用时，一个关键挑战是要设计一个有效的支持并发的read 和 write操作的ORB核心的连接结构。
TCP提供了无类型的TCP提供了无类型的字节流数据传输语义。因此，多个线程不能自同一个socket并发地进行read和write, 同样，对在一个ORB进程内共享的一个socket的写操作必须被串行化，串行化通常是通过一个客户进程在写一个共享socket之前先要得到一个锁这样的方式来实现的。
对于单路操作，当一个请求发出后，并没有必要来设置额外的锁方式或者进程。而对于共享信息的双路复用来说，情况就变得要复杂起来。然而，在这种情况下，ORB核心必须允许多线程协作式的对socket终端进行’read’操作。
如果服务器的应答通过一个单一的TCP连接被多路复用，则多个线程不能同时从哪个socket端点进行读，而是ORB核心必须通过使用同原来的客户请求一起发送和同该伺服程序的应答一起返回的GIOP序列号，多路转发进入的应答到适当的客户线程。
有几种常用的方法来实现连接的多路复用，以允许并发的read 和 write，描述如下：
主动的连接结构：
l 回顾：其中的一种策略是使用图5所示的活动体系架构。一个应用程序线程调用一个双路复用，使得request进入ORB的队列。
(1) ORB核心中有一个独立的线程为这个队列服务。
(2) 并且在众多socket中由ORB线程选择的一个socket上执行write操作。
ORB线程选择的一个socket：一个客户端可能与许多的服务器存在着许多socket连接。
(3) 该ORB线程在这一socket 上执行select操作，等待服务器的应答。
(4) 并且将回复加入一个消息队列。
(5) 最后，应用程序线程重新得到队列的回复消息。
(6) 并将其发回给请求者。
l 优势
主动连接结构的优点在于它通过使用一个相同的排队机制简化了ORB的实现。此外，如果每个socket处理相同优先级的数据报，即不会在同一socket上接收到不同优先级的数据报，主动连接能以先进先出的次序处理这些数据报不会引起请求级的优先级倒置[22]。
l 缺陷
这一结构的缺点是主动连接促使在涉及双向操作时促使额外的上下文切换。因此，为了最小化这一开销，许多ORBs使用主动连接结构的一个变体，描述如下。
领导者/跟随者连接体系
(1).回顾 可替代活动体系架构的另一种模型是如图6所示的领导者/跟随者连接体系。与以往一样，一个应用程序线程调用一个双路复用
(1). 不是将请求排在一个ORB消息队列中，而是直接经socket发送该请求。
(2). 由应用程序线程来调用写操作，而且，在该ORB核心中没有一个线程是专用于处理在leader/follower结构中所有socket I/O。取而代之，在多路复用中第一个等待回应消息的线程将被阻塞。
(3). 这个线程我们称为领导者。为了避免socket的字节流变坏，只有leader线程能执行sockets上的select，这样，所有跟着该leader读取来自该共享 socket的应答的客户线程将封锁在被ORB核心管理的信号灯上。如果应答自服务器中以FIFO顺序返回，这一策略是最佳的，因为没有不必要的处理或上下文切换。由于应答可能以非FIFO顺序到达，来自服务器的下一个应答可能属于被封锁在该信号灯上的任何一个客户线程。当下一个来自服务器的应答到达时，该leader读这一应答，
(4). 它使用在GIOP应答包文头中返回的序列号来确定接收该应答的正确的线程。如果该应答是对leader自己的请求作出的回答，该leader线程释放信号灯上的下一个follower。
(5). 并返回到它的调用程序。
(6). 这下一个follower线程成了新的leader，并执行和封锁在select操作上。
如果该应答不是给该leader线程的，该leader线程必须发信号通知合适的follower线程，然后得到通知的线程被唤醒，读它的应答，并返回到它的调用程序。而其间，该leader线程继续在select中等待下一个应答的到来。
l 优势：与活动连接比较，领导者/跟随者连接体系的优势在于它可以最小化以FIFO次序到达的回应内容交换。
l 缺陷：领导者/跟随者模型的缺陷在于复杂的逻辑执行可以生成锁操作和优先级倒置。锁操作是由于发送请求时原语的需求而生成的。当等待线程的优先级并不被领导线程的优先级所注重时，它多态分接发往客户线程的回应，并可能出现优先级倒置。
3.1.2 非多态连接体系
回顾：最小化ORB核心优先级倒置的一种技术是使用一个非多态连接体系，比如图7所示。在这种连接体系中，每个客户线程保持重复生成的连接来为线程级存储[30]服务。每个具有独立优先级的线程保持一种独立的连接，比如p1,p2,p3。所以，当一个双向连接被调用(1)时，他们并不与其他线程共享SOCKET终端。因此，写(2),选择(3),读取(4),和返回(5)操作可能在没有与进程内其他线程为ORB核心资源竞争的情况下出现。
图7.非多态连接体系
优势：非多态连接体系最主要的优势在于可以保护端到端优先级并且可以当通过ORB终端时最小化优先级倒置。不仅如此，既然连接并不是共享的，这
种设计可以由于当发送和接受双向请求[31]时ORB核心不要求额外的锁操作导致低同步。
l 缺陷：非多态连接体系的缺陷在于它可以使用比多态连接模型更大数量的socket终端，这可能增加ORB终端的存储容量。而且，这种方法并不因优先级的数目来决定。因此，这是配置实时程序最有效的方法，比如电子设备计算系统[22]，这可以处理小数目的连接和优先级体系，而每个优先级体系指向一个OS线程优先级。
3.2 可选择的ORB核心通信体系
有许多构件ORB[26]通信体系的策略。如下，我们描述了许多可选择的ORB核心通信体系，集中在服务器端通信。
3．2．1工作者线程池体系
回顾：这种ORB通信体系使用一种与3.1.1部分描述的活动连接体系相似的设计，如图8所示，工作线程池的组件包括I/O线程，一个请求队列，和一个工作者线程池。I/O线程选择(1)socket端，读(2)新的客户请求，并且把他们插入到请求队列的尾部。一个池中的工作者线程将下一个请求从队列头出队(4)并发送(5)它。
图8.服务器端工作线程池通信体系
l 优势：工作者线程池通信体系最大的优点在于执行的灵活性。特别的，请求队列提供了一种直截了当的生产者/消费者设计模式。
缺陷：主要缺点是过多的上下文切换和过多的管理队列所需要的同步、以及由于连接的多路复用引起的优先级颠倒。稍后到达的一个高优先级请求会等待一个低优先级请求直至它被处理完成。而且，如果原先读请求的线程的优先级低于处理该请求的伺服程序的优先级。
3．2．2领导者/跟随者线程池体系
l
回顾：领导者/跟随者线程池体系是工作者线程池的最佳体系。这与3.1.1部分所述的领导者/跟随者连接体系相似。分配一个线程池，（1）选择一个leader线程，它在服务器进程的所有伺服程序的连接上进行Select（侦听在所有这些连接上是否有请求到达），（2）当一个请求到达时，这一线程将它读到一个内部缓冲区中。如果这是一个伺服程序的一个合法的请求，池中的一个follower被释放，从而成为新的leader，（3）而原来的leader分派这一上向调用，（4）在该上向调用被分派以后，原来的leader成为一个follower并返回到线程池中。新的请求在一个socket端点中排队，直至在池中的一个线程可供使用来执行请求。
图9.服务器端领导者/跟随者通信体系
优势：同工作者线程池设计相比，leader/follower线程池结构的主要好处是将由进入请求引起的上下文切换的开销减至最小，这是因为读一个请求的线程也是处理该请求的线程，而不是一个线程读请求，而由另一个线程来处理请求（这样就发生上下文切换了）。
缺陷：其实现逻辑会产生过多的封锁开销和优先级倒置。且相比之下，难以实现。
3.2.3 线程框架体系
回顾：实现一个ORB并发性结构的一个非常灵活的方法是使得应用开发人员能定制由一个线程化结构提供的hook方法，构造这一框架的一个方法如图10所示。这一设计是基于MT-Orbix线程过滤器框架，这一框架实现了Chain of Responsibility pattern的一个变体[32]。
在MT-Orbix中，一个应用能在一个过滤器链的顶部安装一个线程过滤器，过滤器是应用可编程的hooks，它们能执行许多任务，公用的任务包括拦截、修改、或检查每个进出ORB的请求。
在线程框架结构中，（1）在ORB核心中的一个连接线程从一个socket的端点读一个请求，（2）并将该请求排队至ORB核心的一个请求队列上。（3）然后另一个线程将请求从队列中取出，并相继地通过链中的每一过滤器传递这一请求。（4）最顶上的过滤器，即线程过滤器，确定处理这一请求的线程。在这一线程池模型中，线程过滤器将请求排队至一个由具有合适优先级的一个线程服务的队列中，这一线程然后将控制传递回给ORB，由ORB执行操作的多路转发和分派向上调用。
图10 服务器端线程框架通信体系
优势：一个线程化框架的主要优点是它的灵活性，线程过滤器机制可由服务器的开发人员编程，来支持各种并发性策略。例如，为了实现thread-per-request[33]策略，过滤器可衍生一个新的线程，并将请求传递给这一新的线程。同样，这一MT-Orbix线程化框架还可被配置成实现其它的并发性机制，如thread-per-object[34]和线程池[35]。
缺陷：对于线程框架设计，有几个缺陷。首先，由于只有一个单一的过滤器链，优先级颠倒可能发生，因为每个请求必须以FIFO次序穿越过滤器链。第二，在该ORB端系统中可能会有多个级别的FIFO队列，因此，一个高优先级请求可能会在若干个稍早到达的低优先级请求之后被处理。第三，这一线程框架的通用性可能会极大地增加封锁的开销，因为要将请求插入到合适线程的队列中必须先获得锁。
3．2．4 Reactor-per-Thread-Priority体系
l 回顾：Reactor-per-thread-priority结构基于Reactor模式[36]，它将传输端点的多路转发和对应的事件处理程序集成起来。这一线程结构将一组Reactors同一组以不同优先级运行的线程关联起来。
如图11所示，该Reactor-per-thread-priority结构包括多个预分配的Reactors，每个Reactor都同它自己的适合于ORB中每个优先级（如P1、P2、P3、P4）的实时控制线程关联起来。
在每个线程内，（1）该Reactor 多路转发所有进入的客户请求给合适的连接处理器，如connect1、connect2等，（2）而连接处理器读请求并（3）将它分派给以其线程优先级执行上行调用的一个伺服程序。
图11 服务器端Reactor-per-Thread-Priority通信体系
在一个ORB服务器线程中的每个Reactor还同一个Acceptor相关联，该Acceptor是一个工厂，它在一个特定的端口号上侦听客户连接到哪个线程，并建立一个连接处理器来处理GIOP请求。在图11的例子中，对于每个优先级有一个listener端口。
优势：Reactor-per-thread-priority结构的优点在于它将优先级颠倒和不确定性减至最小。而且，它通过只有当伺服程序越过不同的线程优先级进行交互时才要求伺服程序处于被封锁状态，减少上下文切换和同步开销。此外，这一并发性结构还支持将优先级同速率关联起来的调度和分析技术，如速率固定的调度（RMS）和速率固定的分析（RMA）[39，40]。
缺陷：Reactor-per-thread-priority结构的缺点在于它串行化在一个单一控制线程内的每个Reactor的所有客户请求，这会降低并行性。为了减轻这一问题，这一结构的一个变体将一个线程池同每个优先级别关联起来，虽然这将增加潜在的并行性，它将引起更大的上下文切换和非确定性，这种情况对于某些类型的实时应用来说是不能接受的。
3.2.3整合连接与通信体系
图12 端到端实时ORB核心软件体系
Reactor-per-thread-priority结构能无缝地同非多路复用的连接模型集成，来提供实时ORB端系统中端对端的优先级保持。在这一图式中，Acceptors分别在对应于20 Hz、10 Hz、5 Hz、和 1 Hz速率的组线程优先级的端口上侦听，一旦一个客户连接到了，它的Acceptor创建一个新的socket队列和一个服务该队列的连接处理器。I/O子系统使用包含在到达请求中的端口号作为一个多路转发关键字，来将请求同合适的socket队列关联起来。由一个以适当优先级运行的ORB核心线程来服务每一队列。
Reactor-per-thread-priority结构和非多路复用连接结构的结合通过“急切地”多路转发进入的请求到服务这一优先级的目标伺服程序的适当的实时线程，将穿过整个分布式ORB端系统的优先级颠倒减至最小。在4.2节中将说明，这一设计非常适合具有确定性QoS需求的实时应用。
4.实时ORB核心性能实验
这个部分描述了衡量几个商用和研究型实时系统性能的结果，包括IONA MT-Orbix 2.2, Sun miniCOOL 4.32,Expersoft CORBAplus 2.1.1, and TAO 1.0。MT-Orbix和CORBAplus并不是真正意义上的ORB，他们并不是外部设计来支持实时QoS需求应用程序的。Sun miniCOOL是特别被小型内存的嵌入式系统而设计的COOL ORB的子类。TAO是由华盛顿大学设计专门支持确定性和保持服务质量的一种ORB组件。TAO已经在许多公司的产品中得到应用，比如Boeing [37], SAIC,Lockheed Martin, and Raytheon。
4．1基准测试
这个部分描述了我们设计的系统测试标准来确定延迟时间与吞吐量，以及ORB终端系统中的优先级倒置与非确定因素。我们所阐述的测试温床如图13所示。所使用的硬件与软件环境如下所述。
4.1.1 硬件配置
我们所做的实验使用一个FORE系统ASX-1000 ATM交换机来连接2个多处理器UltraSPARC-2，使用的操作系统是Solaris 2.5.1。ASX-1000的端口是96，OC12拥有622Mb/s的交换速度。每个UltraSPARC-2包括2个168 MHz超级SPARC CPU，和一个1M的cache缓存。Solaris 2.5.1 TCP/IP协议栈使用STREAMS通信架构[41]来执行操作。
每个UltraSPARC-2有256M的RAM和一个ENI-155s-MF的ATM适配卡，这个支持每秒155M的多模式SONET处理速度。ENI ATM适配卡的最大传输单元达到9180比特。每个ENI卡拥有512KB的主板内存。并且每个ATM虚电路连接拥有最多达到32KB的连接带宽和传输速率(共64K)。这允许8台交换机同时虚拟连接同时连接。CORBA/ATM硬件平台如图14所示。
4.1.2客户/服务器配置和基准方法论
几种基准配置：如图13所示，我们的测试服务器包括1个ORB对象适配器中的2个服务进程。一个服务进程以高优先级运行，另一个相对较低。每个线程处理另一个UltraSPARC-2客户线程发送来的请求。
Solaris实时线程[42]经常被用来为服务进程优先级服务。高优先级的服务进程拥有最高的Solaris实时进程，当然，低优先级的服务进程拥有最低的。而服务基准配置是由各种以下ORB来执行：
CORBAplus:使用3.2.1部分描述的工作线程池体系。2.1.1版CORBAplus，多线程应用程序有一个事件分发器和一个工作线程池。分发线程得到发送的请求并且将他们传给工作线程。在最简单的配置情况下，一个服务器应用程序可以不选择创建额外的线程，这取决于处理请求的主线程。
miniCOOL:使用3.2.2部分所述的领导者/跟随者线程池体系。4.3版的miniCOOL允许应用程序级的通信控制。应用程序开发者可以在thread-per-request和thread-pool中进行选择。我们采用thread-pool通信体系，这是由于它比thread-per-request更适合于确定性的实时应用程序。在thread-pool通信体系中，应用程序首先产生一系列的线程。不仅如此，当初始线程池的大小无法满足要求时，miniCOOL可以配置成为服务器程序利益来处理请求，这需要动态分配一个最大数量的线程。
MT-Orbix:使用基于3.2.3部分所述的责任模式链的线程池体系。2.2版的MT-Orbix在开始时创建2个实时服务进程。高优先级线程对应于高优先级服务，低优先级线程对应于低优先级服务。使用Orbix线程过滤机制，传送的请求由这些线程来处理，如图10所示。每个优先级有自己的请求队列来避免优先级倒置。
这种倒置可以由于高优先级和低优先级服务从同一队列中出队而产生。
TAO：使用3.2.4部分所述的Reactor-per-thread-priority通信体系。1.0版的TAO使用非多路连接整合了Reactor-per-thread-priority通信体系，如图15所示。与此相比，其他3种ORB多路复用技术使用单独的连接来从客户端接受请求。
客户基准配置：图13展示了基准测试是如何使用一个高优先级客户C0和低优先级客户C1…Cn,高优先级客户以高优先级运行实时OS线程并且调用20 Hz的操作，它可以调用每秒20次的CORBA双向请求。所有的低优先级客户拥有相同的低优先级OS线程，并且调用的是10Hz的操作。他们调用每秒10次的CORBA双向请求。在每次请求中，客户发送一个特定的八进制CORBA值。服务器将这个立方并返回给客户。
当测试程序创造客户线程时，他们屏蔽一个障碍锁，所以客户必须等到其他线程均被创建以后才能工作。
当所有线程通知主线程已经准备就绪，主线程激活所有客户线程。这些线程以一个Solaris实时线程分发器决定的次序来执行。每个客户以指定的速率调用4000个CORBA双向线程。
4．2 Solaris上的性能测试
我们的实验基准使用2种策略：黑盒与白盒。
黑盒基准：我们计算各个客户的双向回应平均时间。不仅如此，我们还计算双向操作的颠簸时间，这是双向回应时间的标准。高延迟与颠簸并不是实时应用程序所期望得到的，由于他们降低了最坏情况执行时间并减少CPU利用率。4.2.1部分解释了黑盒测试结果。
白盒测试：为了准确的表现出优先级倒置与非确定性能的原因，我们使用白盒基准。这些基准使用UNIX捆绑与量化工具[43]。这些工具跟踪ORB的活动并记录到日志文件中去，同时测量各个任务所花费的时间，正如4.2.2部分所述。
所以，黑盒与白盒基准指示了由CORBA客户导致的端对端的延迟/抖动，并解释了这些结果的原因。总的来说，结果说明了象Orbix, CORBAplus, 和miniCOOL这样的ORB并不适合于实时系统的性能要求。同样地，结果举例认证了TAO使用的非多路，基于优先级的ORB核心体系怎样并且为什么更加适合于实时系统。
4.2.1黑盒结果
随着低优先级客户的增加，低优先级的请求数量也逐渐增加。理想化的说，一个实时ORB终端系统不应该在低优先级请求数量不同时表现出不一致。我们的端对端测量结果如图16所示。
图16展示了随着低优先级客户的增长，MT-Orbix和CORBAplus会导致高优先级客户线程的延迟时间增长。与TAO相比，MT-Orbix的延迟时间是它的7倍，CORBAplus则为25倍。而且，miniCOOL的平均延迟时间具有不规则性，从10豪秒延迟时间运行20个低优先级客户到2豪秒延迟时间运行25个低优先级客户。这些不确定性并不是实时系统所期望得到的。
MT-Orbix和CORBAplus和miniCOOL的低优先级客户也会出现严重的抖动情况。与TAO的最坏情况相比，CORBAplus导致的抖动是其300倍，MT-Orbix则为25倍，如图17所示。同样，miniCOOL的低优先级客户表现了抖动的不稳定性，这使得它并不适合于实时系统。
每种ORB的黑盒测试结果有如下更详细的说明
CORBAplus结果：CORBAplus在图16的许多情况下导致优先级倒置。在展示了一小部分的低优先级客户的高延迟时间后，当客户数量为10时，延迟时间迅速降低，最终却又回升。这种不稳定的表现使得它不适合确定性的实时应用程序。4.2.2部分揭示了这样的低性能与优先级倒置是如何从CORBAplus的通信架构中滋生的。图17展示了CORBAplus产生了高优先级的抖动，特别是当低优先级客户数量为40，45，50时。这样的结果说明应用程序的不稳定性正需要实时保证。
MT-Orbix结果：MT-Orbix在随着低优先级客户增多导致优先级倒置。当客户数量超过10，高优先级客户的性能更逊于低优先级客户。这种情况并不对确定性的实时系统具有益处。4.2.2部分揭示了这些倒置是如何从服务器端的MT-Orbix通信体系中滋生出来。而且，MT-Orbix会造成图17所示的高频率抖动。这种表现是由于ORB核心中的优先级倒置造成，4.2.2部分有介绍。
miniCOOL结果：随着低优先级客户的增加，高优先级客户的延迟时间也随之增加，达到10豪秒20客户，然后迅速下降到2.5秒25客户。这种不确定的表现在低优先级客户增多时更加明显。经管高优先级客户的延迟时间比低优先级客户的更短，客户的非线形行为仍然使miniCOOL并不是确定性实时应用程序的最佳选择。
高低优先级客户间的差异一样难以预测。比如，范围可以在0.55豪秒到10豪秒之间。4.2.2部分揭示了这种情况是如何在miniCOOL的客户与服务器模式下形成。
miniCOOL导致的抖动一样非常高，如图17所示。这种抖动与CORBAplus ORB的情况十分类似，这是由于两者在处理锁操作上花费的时间大致相同。4.2.2部分对锁操作进行了评价。
TAO的结果：图16揭示了随着低优先级客户数量从1增加到50，TAO的高优先级客户延迟时间以0.7豪秒的速率增长。然而，高低优先级客户的区别从0.05豪秒到0.27豪秒不等。与此对比，miniCOOL从0.55豪秒增长到10豪秒,CORBAplus从0.42豪秒增长到15豪秒。而且，TAO的延迟时间增长率远远低于MT-Orbix, Sun miniCOOL, 和 CORBAplus。特别的是，当50个低优先级客户为CPU利用率和网络带宽竞争时，MT-Orbix的低优先级客户延迟时间比TAO的多7倍，miniCOOL则为3倍，CORBAplus为25倍。
与其他ORB相比，TAO的高优先级客户总能比别的低优先级客户表现的更好。这论证了TAO ORB核心的连接与通信体系更适合于保持实时请求的优先级。TAO和其他ORB的关键区别在于它的GIOP协议处理是由专门的端对端优先级实时线程在一个专门的连接上来进行。因此，TAO共享了最小的ORB终端资源，这可以减少优先级倒置和锁操作的机会。
TAO ORB 也展示了非常低的抖动，低优先级(小于11豪秒)，高优先级(小于1豪秒)。TAO延迟时间的稳定性明显正是可预测端到端程序所期望的。
总的说来，以上的黑盒结果描述了ORB核心通信和连接软件体系，这可以在恶化优先级倒置和非确定性上。TAO在Solaris I/O上能够有这样低的延迟时间与抖动证明了使用象CORBA这样的标准OO中间件来支持实时应用程序的可行性。
4.2.2白盒测试结果
对于白盒测试来说，我们使用了10个如同4.1部分所描述的并发的客户。其中9个是低优先级，另一个是高优先级的。每个客户发送4000个双向请求给服务器端，当然，服务器端有1个低优先级服务线程和1个高优先级服务线程。
我们以前使用电子计算[37]CORBA的经验说明锁操作成为实时系统潜在优先级倒置，不确定性的缘由。使用量化与跟踪工具，我们测量ORB在同步，I/O，和协议处理上所花费的时间。而且，我们计算一个记录用户级(互斥锁)和内核级(lwp互斥锁)的处理请求次数标准。这个标准计算出每次请求锁操作的平均次数。总体上，内核级锁被认为更加昂贵，这是因为他们导致用户/内核模式交换。我们实验的白盒测试结果如下所述：
CORBAplus白盒结果：我们对CORBAplus的白盒分析结果揭示了双向连接的用户级同步高频率，如图22所示。锁操作的同步问题执行了图18所示的CORBAplus.通信与连接架构。CORBAplus客户端表现了很高的用户级同步性(52%)，而服务器端为(45%),这是由于内核锁的操作。对于每种CORBA请求/回应模式，CORBAplus的客户ORB执行199种锁操作，而服务器进行216种用户级锁操作，如图22所示。这种锁操作是由于动态内存分配而大量滋生的，如4.4部分所描述。
每种动态分配导致2次用户级锁操作，一个释放而另一个获得。CORBAplus连接和通信体系如下所述。
CORBAplus连接体系：CORBAplus ORB连接体系使用3.1.1部分描述的活动连接模型和图8所展示的模型。这种设计将所有请求多路通过一个活动连接线程分接到相同的服务器，使用统一队列机制简化了ORB执行过程。
CORBAplus通信体系：CORBAplus ORB通信体系使用线程池。3.2.1部分描述
体系和图8所描绘的就是这种机制。这种体系使用一个单独的I/O线程来接收和读取从socket终端来的请求。这个线程将请求插入队列，当然这个队列被一个工作者线程池服务。
CORBAplus连接体系和服务端通信体系帮助减少了同时开放连接并简化了ORB执行。然而，同时到来的请求共享连接导致了高优先级倒置，这是由于每个请求发送自己的操作导致内容交换。而且，在客户端，不同优先级的线程可以共享相同的传输连接，这可能导致优先级倒置。比如，一个高优先级线程可能阻塞，直到一个低优先级线程结束发送它的请求。同时，线程的优先级不一定会影响到达服务器端请求的优先级，因此会导致额外的优先级倒置。
miniCOOL whitebox results：我们对miniCOOL的白盒分析揭示了互斥的同步锁操作会花费非常大百分比的miniCOOL ORB处理时间。与CORBAplus一样，miniCOOL的同步问题是由于执行连接与通信的锁操作造成的。锁操作在客户端需要50%，服务器端则超过40%，如图19所示。
对于每种ORB请求/回应模式，miniCOOL的客户ORB有94次用户级锁操作，而服务器有231次，如图22所示。与CORBAplus一样，由于过度动态内存分配，锁操作大量滋生。每次动态分配导致2次用户级锁操作，一个释放，另一个获得。
每次请求的服务器端锁操作机制造成的调用(如图23所示)往往很高。在Solaris上，这可能由于miniCOOL使用”系统范围”线程，这对于所有同步操作[44],都需要内核级干涉。miniCOOL连接与通信体系如下所示
l miniCOOL 连接体系:miniCOOL ORB连接体系使用3.1.1所描述的领导者/跟随者模型。这种体系允许领导者线程在共享连接上阻塞select操作。所有跟随者线程等待以下的一个或两个条件：(1)领导者线程可以read他们的回复信息，并且标记出旗语。(2)领导者县城可以read他自己的回应，并标记另一个线程进入并阻塞select，因此成为新的领导者。
l miniCOOL 通信体系:Sun miniCOOL ORB通信体系使用3.2.2部分描述的领导者/跟随者线程池体系。这种体系等待一个单独线程内的连接。无论何时一个请求到达并且确认完成后，领导者线程(1)标记一个池中的跟随者线程来等待即将到来的请求(2)并为其服务。
miniCOOL连接体系和服务器端通信体系帮助减少了同时开发连接的数量和当回复以FIFO次序到达时的内容交换。与CORBAplus一样，这种设计导致高优先级倒置。比如，不同优先级的线程可以共享客户端相同的传输连接。因此，一个高优先级线程可能在低优先级线程完成发送请求前一直阻塞。而且，线程的优先级阻塞到达连接并不一定会影响response到达服务器端的优先级，这可能导致额外的优先级倒置。
MT-Orbix whitebox results:图20展示了客户端和MT-Orbix服务器端的白盒结果MT-Orbix连接体系：与miniCOOL类似，MT-Orbix使用领导者/跟随者多元连接体系。尽管这种模型将内容交换最小化了，但仍然会导致严重的优先级倒置。
MT-Orbix 通信体系：在我们的MTOrbix执行基准上，多元服务线程被创建，其中每个为合适的优先级服务。高优先级服务有最高的优先级线程。一个线程过滤器被安装来处理每个请求，决定请求的优先级(检查目标对象)，并将请求以正确的优先级传给线程。线程过滤器机制是由一个高优先级实时线程来实现的，它最小化分发延迟。
线程池将3.2.3部分所示例的MT-Orbix机制实例化，并使其灵活好用。然而，它却遭受高频率的优先级倒置和同步问题。MT-Orbix提供一条过滤链。因此，所有达到的请求必须在被传到服务线程前由过滤器连续的处理。因此，如果一个高优先级请求在一个低优先级请求之前到达，它必须等待直到低优先级请求被ORB处理后被分发。
不仅如此，一个过滤器只是在GIOP(1)处理完后，并且适配器(2)决定了目标对象后才可以被调用。这个处理过程由于MT-Orbix ORB核心并不知道请求的优先级而被序列化。因此，一个在低优先级请求达到后来的高优先级请求必须等待，知道低优先级请求被MT-Orbix处理完成。
. MT-Orbix通信体系主要对它的子系统优先级倒置负责，如图16所示。这张图展示了高优先级客户的延迟是如何快速的增长，从2豪秒快速增长到14豪秒的。
MT-Orbix过滤机制也导致了同步问题的增长。这是由于只有一个过滤链，通信请求必须获得并且释放过滤器所要处理的锁。MT-Orbix客户端在每个请求中表现出175个用户级锁操作，而服务器端表现出599个，如图22所示。而且，MT-Orbix展示了高密度的内核级锁操作，如图23所示。
TAO
的白盒结果：
如图
21
所示，
TAO
表现出可忽略的同步问题。
TAO
在客户端不会有用户级锁操作，同样服务器端也不会。这是由于
TAO
的核心设计所决定的，它为每个优先级建立一个连接，如图
12
所示。因此，
TAO
的
ORB
核心不存在用户级和内核级锁操作。
TAO的连接体系：TAO 使用非多元的连接体系，这重复建立到服务器的连接，如3.1.2部分所述。其中一个连接是为每个优先级建立的，因此避免了动态连接中的非确定性延迟。而且，不同优先级有着自己的连接。这种设计模式避免了请求级优先级倒置，这可能以FIFO顺序排列，并由客户线程以不同优先级处理。
TAO通信体系：TAO支持几种通信体系，比如[22]所描述。3.2.4部分所描述的Reactor-per-thread-priority体系被用来作为本篇的基准。在这种通信体系中，为每个优先级创造一个独立的线程。因此，低优先级客户以比高优先级客户低的速率发送CORBA请求。(10Hz Vs 20Hz)
在服务器端，发送的高优先级客户请求被一个高优先级实时线程所处理。同样，发送到低优先级服务的客户请求由低优先级实时线程所处理。由于这2个服务线程共享ORB资源，他们分离了Reactors,Acceptors,Object Adapters。而且，这2个线程为不同的客户连接服务，因此排除了优先级倒置,如同我们测试的其他ORB一样
锁操作：我们的白盒测试基准测量了CORBAplus,MTOrbix,miniCOOL,和TAO ORB的用户级锁操作(如图22所示)和内核级锁操作(如图23所示)。用户级锁操作是典型的用来保护一个进程中共享资源的。一个普通的例子是使用全局C++操作符new和delete来动态内存分配。这些操作符从每个进程中的全局管理堆中分配内存。
用户级锁操作则更为昂贵，这是由于他们需要在用户级与内核之间进行模式交换。旗语和互斥操作在对ORB内核级锁操作评估的白盒测试结果中表现出来。
图22和23举例说明了其他3种ORB，TAO却不会导致用户级与内核级的锁操作。我们可以对TAO进行设置，使其不会让ORB资源被其线程共享。比如，它使用重复分配的实时栈缓冲区来减少了动态内存分配，及其相关的锁操作。每个缓冲区被划分开来，以支持各种各样的请求。
4．3 Chorus ClassiX的性能结果：
4.2部分所述的性能结果是从Solaris2.5.1上得到的，它提供实时时序但不提供实时I/0[42]。因此，Solaris不能保证象I/O缓冲这样的资源的可用性及网络带宽[22]。而且，SolarisI/O子系统表现出的时序并不是和其他资源整合的。这允许应用程序确保Qos需求得以满足。实时操作系统所提供的QoS机制包括实时时序类。他们保证Qos，以及实时I/O。Chorus ClassiX是一个可以配置在嵌入式系统中的实时OS，也可以在分布式POSIX-compliant平台[45]上进行。ClassiX提供了一个实时时序控制以支持几种时序算法，包括基于FIFO的时序算法。它支持实时应用程序和综合应用程序。
IPC机制使用在on ClassiX, Chorus IPC上，提供一种有效的，本地传输的基于消息通信方式，这是在一块单一主板和其他连接主板之间的。而且， ClassiX有一个TCP/IP协议栈，可以被Socket API获取，以允许通过网络与其他OS平台进行通信。
. 为了确定实时OS在ORB性能上的影响，这种子类划分代表了TAO的黑盒结果和使用ClassiX的miniCOOL。
4.3.1 硬件配置
以下的实验使用2个MVME177 VMEbus单主板计算机。每个MVME177包括一
个60MHz的MC68060处理器和一个64M的RAM。MVME177主板被挂在一
个MVME954A ,6-slot,32-bit，VME-板底。而且，每个MVME177模块有82596CA
以太接受器接口。
4.3.2软件配置
我们的实验在运行ClassiX3.1版本的计算机上执行。ORB基准是miniCOOL4.3和TAO1.0。客户/服务器配置在本地(1)，客户与服务器在相同的主板上。客户/服务器基准配置以在Solaris2.5.1上相同的方式执行，如4.1.2部分所述。MiniCOOL被配置成在主板上发送消息，或者使用Chorus IPC通信工具，这比Chorus TCP/IP协议栈更有效率。而且，我们引导miniCOOL和TAO的基准，使用TCP协议。总的来说，使用Chorus IPC作为传输机制的miniCOOL表现出更加出色的可预见性。
4.3.3黑盒测试结果：
我们计算出各种客户平均的双向回应时间。而且，我们计算出双向操作的抖动时间。高延迟与抖动时间并不是实时应用程序所期望的，这是由于他们可以加剧最坏执行时间和减少CPU利用率。
MiniCOOL,使用Chorus IPC:随着低优先级客户数量的增长，远程高低优先级客户数量也相应增长。当达到34豪秒时，成直线增长趋势，如果客户与服务器在不同的处理器板上，如图24所示。
当客户与服务器被配置好以后，在高低优先级客户上表现出更加稳定的性能。延迟时间从2.5豪秒开始增长到12.5豪秒。同样高和低优先级导致大约相同的平均延迟时间。
在所有的情况下，高优先级客户的延迟时间总是比低优先级客户的要少，因此，不会出现严重的优先级倒置，这正是一个实时系统所期望的。然而，高优先级客户仍然会有延迟时间，而且是对所的远程和本地配置。
、
