论文部分内容阅读
摘要：实现符合minCORBA规范的嵌入式CORBA是为了支持多种资源有限的嵌入式操作系统。为建立这种嵌入式CORBA，本文主要就是基于minCORBA规范对嵌入式CORBA的整体结构、对象请求代理、可移植对象适配器以及IDL（Interface Definition Language）编译器各方面进行设计和实现。
关键词：CORBA；minimumCORBA；实时CORBA；平台依赖层
中图分类号：TP316 文献标识码：A文章编号：1009-3044(2007)04-11032-04
1引言
为满足日益增长的嵌入式系统之间以及嵌入式系统与普通桌面、服务器系统之间协同工作的需求，OMG(Object Management Group，对象管理组织) 针对嵌入式系统资源有限的特点，在保证应用的可移植性和ORB（Object Request Broker，对象请求代理）间的互操作性以及对IDL完全支持下，对完整的CORBA规范进行了裁减，并在2000年底推出了面向嵌入式系统的minimumCORBA规范，并在推出CORBA3.0规范时将其单独列出。
在国外，嵌入式CORBA产品也才问世不久。其中，针对电信领域的主要有：Visibroker For Tornado ＆pSoS及e*ORB；针对控制和军事领域的主要有ORBExpress 和HardPack。它们都符合minimumCORBA规范且性能优良，但其价格较昂贵。在国内，国防科技大学推出的StarBus，是国内第一个嵌入式CORBA产品。它主要通过扩展SUN IIOP而形成。但它并不完全符合mininumCORBA规范。因此，实现国产的完全符合minimumCORBA规范、能够支持多种嵌入式操作系统的嵌入式CORBA很有必要。
本文就基于minimumCORBA规范如何设计与实现能够支持多种嵌入式操作系统的嵌入式CORBA进行了研究，介绍了嵌入式CORBA整体框架搭建、对象请求代理的分层实现、POA（Portable Object Adapter，可移植对象适配器）主要类的实现以及IDL的优化，重点集中在保证整个系统实时性的平台依赖层的实现上面。
2 嵌入式CORBA的整体结构
由于嵌入式系统资源有限，minimumCORBA规范去掉了动态调用接口（DII）和动态框架接口（DSI），除保留RepisitoryIds和TypeCode两部分外，接口库的大部分被去掉。裁减了可移植对象适配器(POA)中的AdapterActivator、ServantManagerse及一些策略取值，动态Any值的管理、拦截器、COM与CORBA之间的互操作也被裁减。符合minimumCORBA规范的嵌入式CORBA，其整体结构如图1。
3 ORB的分层设计和实现策略
图1 嵌入式CORBA的整体结构
若将ORB作为一个整体来设计，会由于其和具体操作系统有较强的依赖关系，使其过于复杂，不易移植。因此，应采取分层设计的方法，将ORB分成ORB接口实现、ORB与平台相关、ORB通信三层。如图2：
图2 ORB分层示意图
3.1 ORB接口层
ORB接口层分ORB核心、客户端ORB和服务端ORB三部分来设计和实现。同时还应选择合适的并发模式。并发模式是指ORB如何处理通信和请求执行。
3.1.1 ORB核心
应设计的类及其功能如表1所示：
表1 ORB核心类表
3.1.2 客户端ORB
客户端ORB根据对象引用构造并传送请求。为使客户端的通信和其他操作并行进行，客户端ORB的并发模式为用一个单独的接收线程接收来自服务端的回应。应设计的类及其功能如表2所示：
表2 客户端ORB类表
其中，客户端ORB控件类继承ORB核心中的ORB控制类，客户端ORB实例类继承ORB核心中的ORB实例类。
3.1.3 服务端ORB
服务端ORB侦听并接收请求。实际应用中，服务端一般不会有太多请求，但通常要求服务端立即响应请求。服务端并发模式为用一个独立的线程来侦听连接，当连接到来后，对应每个请求生成一个新接收线程，当向客户端发送请求对应的应答时，生成的接收线程被销毁。这样每个请求就在服务端得到立即响应。其缺点是生成新线程要消耗一定的CPU和内存资源。在许多嵌入式操作系统中，没有线程的概念，只有任务。此时任务就和线程类似。应设计的类及其功能如表3所示：
表3 客户端ORB类表
其中，服务端ORB控件类继承于ORB核心中的ORB控制类，服务端ORB实例类继承于ORB核心中的ORB实例类。
3.2 ORB平台依赖层
CORBA规范是针对对象请求代理系统制定的规范。ORB直接置于操作系统之上，这使得ORB对具体的操作系统具有较强的依赖关系。为了使ORB具有很好的可移植性，在设计ORB时，将这些依赖关系抽象出来，作为平台依赖层来实现（如图3），这就去掉了ORB与具体操作系统的强耦合关系，使其具有很好的可移植性。针对不同的操作系统，只要对平台依赖层进行相应的修改，就可以很容易地将ORB移植到不同的操作系统之上。
图3 平台依赖层
平台依赖层的设计吸收了Java的线程管理风格，并采用了面向对象的设计思想，具有使用简单、修改容易的优点。作为通用的线程平台，平台依赖层首先应具有通用线程功能，同时平台依赖层还强调对于实时应用的支持，所以必须提供如下的实时功能：
（1）配置和管理应用程序的优先级类别；
（2）实时CORBA优先级到具体操作系统优先级的映射；
（3）高优先级线程抢占低优先级线程的执行；
（4）具有相同优先级的线程按照时间片轮转方式调度执行；
（5）能够避免优先级反转，通过实现一个带优先级继承的互斥锁来避免优先级反转带来的对实时可预测性的负面影响，这是保证实时线程可预测性的重要条件。
3.2.1 优先级映射
为了屏蔽操作系统的差异，实时CORBA将优先级区分为两种：CORBA优先级和本地优先级，CORBA优先级是独立于任何具体操作系统的优先级，本地优先级是具体操作系统的优先级，本地优先级的特性由具体的操作系统决定，本地优先级的差异主要体现在优先级级别个数上的不同、优先级高低与优先级值的关系不同（有的操作系统优先级值越小，级别越高）。
平台依赖层采取的映射法的基本思想如下：假设系统有N个本地优先级，在某一时刻，系统需要有M个CORBA优先级级别需要映射。如果MN，这在该时刻，从M个CORBA优先级中选择N个（选择优先级高的前N个），将它们映射到本地优先级，其他CORBA优先级在M-N中的线程则被暂停执行。当需要映射的CORBA优先级级别发生变化时，需要重新调整映射，所以这种方法是一种动态的映射方法。
优先级映射需要在平台依赖层中设置一个调度线程，它通常运行在系统的最高优先级，并监控系统状态，当状态发生改变时，按照映射的方法，重新调整系统的优先级映射。
优先级映射必须定时、周期地进行，以便及时排除退出的线程和不满足运行条件的线程。优先级映射除了定时执行外，线程设置优先级和有新线程创建和销毁时都要重新映射。
3.2.2 固定优先级调度策略
通用操作系统中的线程调度策略一般采用基于优先级的抢占式调度策略，对于优先级相同的进程则采用时间片轮转调度方式，用户进程可以通过系统调用动态的调整自己的优先级，操作系统也可以根据情况调整某些进程的优先级。固定优先级调度方式则与通用操作系统中采用的基于优先级的调度方式基本相似，但在固定优先级调度方式中，进程的优先级是固定不变的，并且该优先级是在运行前通过某种优先级分配策略来指定的，这个优先级只能应用程序本身才能够改变，这种策略也叫静态优先级。
由于不同的操作系统平台的线程存在差异，平台依赖层在实现固定优先级调度时分别予以考虑。
在Win32线程环境下，优先级分为两类：实时和动态，并提供32个线程优先级(0-31)。实时类线程有一个固定的优先级(16-31)，这个优先级只有应用程序本身才能改变；动态类是操作系统为了达到更好的交互性能，会适时地动态调整的一种优先级(0-15)，调整的范围最多向上浮动8个单位，且不能超过15。只有实时级的线程才具有固定优先级的调度能力，所以在平台依赖层库初始化时，必须将线程的优先级类设置为实时级，通过优先级映射机制，把应用程序内的所有线程优先级映射在16到31之间，这样可以满足所有线程按固定优先级抢先调度。
在其他的嵌入式操作系统环境下，比如Wind River公司的VxWorks系统 ,北京科银京城公司的道系统DeltaOS，可以利用这些操作系统本身对实时优先级的支持来实现固定优先级抢先调度。
3.2.3 互斥锁设计，防止优先级反转
优先级反转是一种不确定的延迟形式，经常出现在存在共享资源的、多线程的、可抢占的应用中。当高优先级线程企图访问已被某低优先级线程占有的共享资源时，就会引起优先级反转。高优先级线程必须等待直到低优先级线程释放它占有的资源，若此时此低优先级线程被一个或多个中等优先级线程所阻塞，问题就变得更严重，因为低优先级线程不能执行，从而不能使用并释放资源。这样，低优先级线程就会以一个不确定的时间阻塞高优先级的线程。
防止优先级反转有两种方法：优先级继承协议（Priority Inheritance）和优先级天花板（Priority Ceiling）。平台依赖层在简单互斥锁和递归互斥锁内实现了优先级继承协议，其具体算法如下：
定义锁对象：
根据算法，如果线程加锁不成功，并且优先级比拥有锁的线程的优先级高，则会临时提升拥有锁的线程的优先级，满足优先级继承协议，可以防止优先级反转。
3.3 ORB通信层
应使ORB通信层能方便地插入不同网络协议，这样的通信接口层叫可插入协议层(PPL，Pluggable Protocol Layer)。如图4所示：
图4 可插入协议层
它支持面向连接的，可靠的字节流协议。TCP/IP是一种可选的PPL插件。因为ORB Core使用了GIOP，这样TCP/IP插件就实现了IIOP协议。其它可选的协议还有SCCP(Signaling Connection Control Part, part ofSS.7)或SAAL(SignalingATMAdaptationLayer)。不可靠的或非面向连接的协议也能使用，只要这些协议插件自身处理了可靠性和连接管理。如只要UDP/IP协议插件提供了数据报的保序和在数据报丢失时数据报的重传，UDP/IP协议就可以使用。在已实现的DeltaCORBA中，实现了对UDP协议插件的支持。
实现PPL层，可采取分层和注册机制以及工厂模式来实现。应设计的抽象类及其功能如表4所示：
表4 PPL抽象类图
4 可移植对象适配器（POA）
可移植对象适配器（POA）将CORBA概念中的对象映射为实际编程语言中的对象。其主要功能为：对象引用的生成和管理、对象实现的登记和管理、对象引用到对象实现的映射、请求的分派。
表5 POA类表
5 IDL编译器（IDLCompiler）
对嵌入式CORBA，应设计一个具有自动优化功能的编译器，它生成的客户端存根和服务器框架能预测地执行封装和解封装，尽量少使用动态内存分配和数据拷贝等代价大的操作。因此应减少动态内存的使用，对所用客户和服务器之间需要交换的消息，IDL编译器应进行存储需求的仔细分析。如预先分配足够的内存，以避免在运行时反复地进行存储是否足够可用的测试；用运行栈来为不封装的参数进行存储分配等。减小数据拷贝，IDL编译器应分析何时可能对原子类型数据执行块拷贝，而不是单个拷贝；减少过度的数据访问，使加载和存储指令的数量最小。减小函数调用代价，IDL编译器应选择性地优化小的存根，通过内联，减小使用这些小的存根函数的调用代价。
为使IDL编译器生成的服务器框架中，能高效地定位客户端的请求，在设计IDL编译器，使用了根据具体关键字表，生成对应高性能哈希算法的技术。实现时主要使用了两种数据结构，一个是关键字签名链表，它每个结点的内容是对应关键字的子串，用来生成相应的哈希值；另一个是伙伴值数组，它是关键字签名表索引而生成，用来在构造哈希函数时快速查找。哈希值的生成算法为：伙伴值数组中字符串第一个字符加上最后一个字符再加上其在伙伴值数组中的索引号。高性能哈希函数的主要生成算法是：顺序遍历关键字签名表，对每个子串，计算其哈希值并放入一数组中，若某一子串的哈希值与前面已计算出的哈希值相同，则表明有冲突，调用相应的冲突解决策略。由于所有的冲突在生成哈希函数时就已解决，因此，生成的哈希函数将是对应关键字值的无冲突的高效哈希算法。
冲突解决策略为：对称差集法。对称差集的定义是，若有集合A、B，则定义集合{A∪B}―{A∩B}为集合A、B的对称差集。策略冲突策略举例说明：若有关键字签名表项’an’和’ar’的哈希值发生冲突，则取其对称差集’nr’；将对称差集中的’n’或’r’增1，再计算哈希值，直到不再冲突为止。
6 总结
本文基于minimumCORBA规范，提出了嵌入式CORBA的具体的设计与实现思路，并在实践中按此思路采用C++语言成功地实现了一个嵌入式CORBA产品──DeltaCORBA。DeltaCORBA支持桌面操作系统Windows、Linux；WindRiver公司的嵌入式操作系统Vxworks、北京科银京成公司的道系统DeltaOS。
参考文献：
[1]Object Management Group.Real-time CORBA1.0[S] March (1999).
[2]Douglas Schmidt,Fred Kuhns.An Overview of Real-Time CORBA Specification[J].IEEE Computer,(2000) 56-63.
[3]Lui Sha,Pagaathan Pajknmar.Priority Inheritance and protocols:An Approach to Real-Time Synchronization .IEEE Trans .On Computer,(1990) 1175-1185
[4]Bil Lewis, Multithreaded Programming with Java Technology, Prentice Hall PTR, USADecember 01, (1999)
[5]Kleiman, Shah, Smaalders. Programming with Threads. Prentice Hall,USA,(1996)
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。
关键词：CORBA；minimumCORBA；实时CORBA；平台依赖层
中图分类号：TP316 文献标识码：A文章编号：1009-3044(2007)04-11032-04
1引言
为满足日益增长的嵌入式系统之间以及嵌入式系统与普通桌面、服务器系统之间协同工作的需求，OMG(Object Management Group，对象管理组织) 针对嵌入式系统资源有限的特点，在保证应用的可移植性和ORB（Object Request Broker，对象请求代理）间的互操作性以及对IDL完全支持下，对完整的CORBA规范进行了裁减，并在2000年底推出了面向嵌入式系统的minimumCORBA规范，并在推出CORBA3.0规范时将其单独列出。
在国外，嵌入式CORBA产品也才问世不久。其中，针对电信领域的主要有：Visibroker For Tornado ＆pSoS及e*ORB；针对控制和军事领域的主要有ORBExpress 和HardPack。它们都符合minimumCORBA规范且性能优良，但其价格较昂贵。在国内，国防科技大学推出的StarBus，是国内第一个嵌入式CORBA产品。它主要通过扩展SUN IIOP而形成。但它并不完全符合mininumCORBA规范。因此，实现国产的完全符合minimumCORBA规范、能够支持多种嵌入式操作系统的嵌入式CORBA很有必要。
本文就基于minimumCORBA规范如何设计与实现能够支持多种嵌入式操作系统的嵌入式CORBA进行了研究，介绍了嵌入式CORBA整体框架搭建、对象请求代理的分层实现、POA（Portable Object Adapter，可移植对象适配器）主要类的实现以及IDL的优化，重点集中在保证整个系统实时性的平台依赖层的实现上面。
2 嵌入式CORBA的整体结构
由于嵌入式系统资源有限，minimumCORBA规范去掉了动态调用接口（DII）和动态框架接口（DSI），除保留RepisitoryIds和TypeCode两部分外，接口库的大部分被去掉。裁减了可移植对象适配器(POA)中的AdapterActivator、ServantManagerse及一些策略取值，动态Any值的管理、拦截器、COM与CORBA之间的互操作也被裁减。符合minimumCORBA规范的嵌入式CORBA，其整体结构如图1。
3 ORB的分层设计和实现策略
图1 嵌入式CORBA的整体结构
若将ORB作为一个整体来设计，会由于其和具体操作系统有较强的依赖关系，使其过于复杂，不易移植。因此，应采取分层设计的方法，将ORB分成ORB接口实现、ORB与平台相关、ORB通信三层。如图2：
图2 ORB分层示意图
3.1 ORB接口层
ORB接口层分ORB核心、客户端ORB和服务端ORB三部分来设计和实现。同时还应选择合适的并发模式。并发模式是指ORB如何处理通信和请求执行。
3.1.1 ORB核心
应设计的类及其功能如表1所示：
表1 ORB核心类表
3.1.2 客户端ORB
客户端ORB根据对象引用构造并传送请求。为使客户端的通信和其他操作并行进行，客户端ORB的并发模式为用一个单独的接收线程接收来自服务端的回应。应设计的类及其功能如表2所示：
表2 客户端ORB类表
其中，客户端ORB控件类继承ORB核心中的ORB控制类，客户端ORB实例类继承ORB核心中的ORB实例类。
3.1.3 服务端ORB
服务端ORB侦听并接收请求。实际应用中，服务端一般不会有太多请求，但通常要求服务端立即响应请求。服务端并发模式为用一个独立的线程来侦听连接，当连接到来后，对应每个请求生成一个新接收线程，当向客户端发送请求对应的应答时，生成的接收线程被销毁。这样每个请求就在服务端得到立即响应。其缺点是生成新线程要消耗一定的CPU和内存资源。在许多嵌入式操作系统中，没有线程的概念，只有任务。此时任务就和线程类似。应设计的类及其功能如表3所示：
表3 客户端ORB类表
其中，服务端ORB控件类继承于ORB核心中的ORB控制类，服务端ORB实例类继承于ORB核心中的ORB实例类。
3.2 ORB平台依赖层
CORBA规范是针对对象请求代理系统制定的规范。ORB直接置于操作系统之上，这使得ORB对具体的操作系统具有较强的依赖关系。为了使ORB具有很好的可移植性，在设计ORB时，将这些依赖关系抽象出来，作为平台依赖层来实现（如图3），这就去掉了ORB与具体操作系统的强耦合关系，使其具有很好的可移植性。针对不同的操作系统，只要对平台依赖层进行相应的修改，就可以很容易地将ORB移植到不同的操作系统之上。
图3 平台依赖层
平台依赖层的设计吸收了Java的线程管理风格，并采用了面向对象的设计思想，具有使用简单、修改容易的优点。作为通用的线程平台，平台依赖层首先应具有通用线程功能，同时平台依赖层还强调对于实时应用的支持，所以必须提供如下的实时功能：
（1）配置和管理应用程序的优先级类别；
（2）实时CORBA优先级到具体操作系统优先级的映射；
（3）高优先级线程抢占低优先级线程的执行；
（4）具有相同优先级的线程按照时间片轮转方式调度执行；
（5）能够避免优先级反转，通过实现一个带优先级继承的互斥锁来避免优先级反转带来的对实时可预测性的负面影响，这是保证实时线程可预测性的重要条件。
3.2.1 优先级映射
为了屏蔽操作系统的差异，实时CORBA将优先级区分为两种：CORBA优先级和本地优先级，CORBA优先级是独立于任何具体操作系统的优先级，本地优先级是具体操作系统的优先级，本地优先级的特性由具体的操作系统决定，本地优先级的差异主要体现在优先级级别个数上的不同、优先级高低与优先级值的关系不同（有的操作系统优先级值越小，级别越高）。
平台依赖层采取的映射法的基本思想如下：假设系统有N个本地优先级，在某一时刻，系统需要有M个CORBA优先级级别需要映射。如果M
优先级映射需要在平台依赖层中设置一个调度线程，它通常运行在系统的最高优先级，并监控系统状态，当状态发生改变时，按照映射的方法，重新调整系统的优先级映射。
优先级映射必须定时、周期地进行，以便及时排除退出的线程和不满足运行条件的线程。优先级映射除了定时执行外，线程设置优先级和有新线程创建和销毁时都要重新映射。
3.2.2 固定优先级调度策略
通用操作系统中的线程调度策略一般采用基于优先级的抢占式调度策略，对于优先级相同的进程则采用时间片轮转调度方式，用户进程可以通过系统调用动态的调整自己的优先级，操作系统也可以根据情况调整某些进程的优先级。固定优先级调度方式则与通用操作系统中采用的基于优先级的调度方式基本相似，但在固定优先级调度方式中，进程的优先级是固定不变的，并且该优先级是在运行前通过某种优先级分配策略来指定的，这个优先级只能应用程序本身才能够改变，这种策略也叫静态优先级。
由于不同的操作系统平台的线程存在差异，平台依赖层在实现固定优先级调度时分别予以考虑。
在Win32线程环境下，优先级分为两类：实时和动态，并提供32个线程优先级(0-31)。实时类线程有一个固定的优先级(16-31)，这个优先级只有应用程序本身才能改变；动态类是操作系统为了达到更好的交互性能，会适时地动态调整的一种优先级(0-15)，调整的范围最多向上浮动8个单位，且不能超过15。只有实时级的线程才具有固定优先级的调度能力，所以在平台依赖层库初始化时，必须将线程的优先级类设置为实时级，通过优先级映射机制，把应用程序内的所有线程优先级映射在16到31之间，这样可以满足所有线程按固定优先级抢先调度。
在其他的嵌入式操作系统环境下，比如Wind River公司的VxWorks系统 ,北京科银京城公司的道系统DeltaOS，可以利用这些操作系统本身对实时优先级的支持来实现固定优先级抢先调度。
3.2.3 互斥锁设计，防止优先级反转
优先级反转是一种不确定的延迟形式，经常出现在存在共享资源的、多线程的、可抢占的应用中。当高优先级线程企图访问已被某低优先级线程占有的共享资源时，就会引起优先级反转。高优先级线程必须等待直到低优先级线程释放它占有的资源，若此时此低优先级线程被一个或多个中等优先级线程所阻塞，问题就变得更严重，因为低优先级线程不能执行，从而不能使用并释放资源。这样，低优先级线程就会以一个不确定的时间阻塞高优先级的线程。
防止优先级反转有两种方法：优先级继承协议（Priority Inheritance）和优先级天花板（Priority Ceiling）。平台依赖层在简单互斥锁和递归互斥锁内实现了优先级继承协议，其具体算法如下：
定义锁对象：
根据算法，如果线程加锁不成功，并且优先级比拥有锁的线程的优先级高，则会临时提升拥有锁的线程的优先级，满足优先级继承协议，可以防止优先级反转。
3.3 ORB通信层
应使ORB通信层能方便地插入不同网络协议，这样的通信接口层叫可插入协议层(PPL，Pluggable Protocol Layer)。如图4所示：
图4 可插入协议层
它支持面向连接的，可靠的字节流协议。TCP/IP是一种可选的PPL插件。因为ORB Core使用了GIOP，这样TCP/IP插件就实现了IIOP协议。其它可选的协议还有SCCP(Signaling Connection Control Part, part ofSS.7)或SAAL(SignalingATMAdaptationLayer)。不可靠的或非面向连接的协议也能使用，只要这些协议插件自身处理了可靠性和连接管理。如只要UDP/IP协议插件提供了数据报的保序和在数据报丢失时数据报的重传，UDP/IP协议就可以使用。在已实现的DeltaCORBA中，实现了对UDP协议插件的支持。
实现PPL层，可采取分层和注册机制以及工厂模式来实现。应设计的抽象类及其功能如表4所示：
表4 PPL抽象类图
4 可移植对象适配器（POA）
可移植对象适配器（POA）将CORBA概念中的对象映射为实际编程语言中的对象。其主要功能为：对象引用的生成和管理、对象实现的登记和管理、对象引用到对象实现的映射、请求的分派。
表5 POA类表
5 IDL编译器（IDLCompiler）
对嵌入式CORBA，应设计一个具有自动优化功能的编译器，它生成的客户端存根和服务器框架能预测地执行封装和解封装，尽量少使用动态内存分配和数据拷贝等代价大的操作。因此应减少动态内存的使用，对所用客户和服务器之间需要交换的消息，IDL编译器应进行存储需求的仔细分析。如预先分配足够的内存，以避免在运行时反复地进行存储是否足够可用的测试；用运行栈来为不封装的参数进行存储分配等。减小数据拷贝，IDL编译器应分析何时可能对原子类型数据执行块拷贝，而不是单个拷贝；减少过度的数据访问，使加载和存储指令的数量最小。减小函数调用代价，IDL编译器应选择性地优化小的存根，通过内联，减小使用这些小的存根函数的调用代价。
为使IDL编译器生成的服务器框架中，能高效地定位客户端的请求，在设计IDL编译器，使用了根据具体关键字表，生成对应高性能哈希算法的技术。实现时主要使用了两种数据结构，一个是关键字签名链表，它每个结点的内容是对应关键字的子串，用来生成相应的哈希值；另一个是伙伴值数组，它是关键字签名表索引而生成，用来在构造哈希函数时快速查找。哈希值的生成算法为：伙伴值数组中字符串第一个字符加上最后一个字符再加上其在伙伴值数组中的索引号。高性能哈希函数的主要生成算法是：顺序遍历关键字签名表，对每个子串，计算其哈希值并放入一数组中，若某一子串的哈希值与前面已计算出的哈希值相同，则表明有冲突，调用相应的冲突解决策略。由于所有的冲突在生成哈希函数时就已解决，因此，生成的哈希函数将是对应关键字值的无冲突的高效哈希算法。
冲突解决策略为：对称差集法。对称差集的定义是，若有集合A、B，则定义集合{A∪B}―{A∩B}为集合A、B的对称差集。策略冲突策略举例说明：若有关键字签名表项’an’和’ar’的哈希值发生冲突，则取其对称差集’nr’；将对称差集中的’n’或’r’增1，再计算哈希值，直到不再冲突为止。
6 总结
本文基于minimumCORBA规范，提出了嵌入式CORBA的具体的设计与实现思路，并在实践中按此思路采用C++语言成功地实现了一个嵌入式CORBA产品──DeltaCORBA。DeltaCORBA支持桌面操作系统Windows、Linux；WindRiver公司的嵌入式操作系统Vxworks、北京科银京成公司的道系统DeltaOS。
参考文献：
[1]Object Management Group.Real-time CORBA1.0[S] March (1999).
[2]Douglas Schmidt,Fred Kuhns.An Overview of Real-Time CORBA Specification[J].IEEE Computer,(2000) 56-63.
[3]Lui Sha,Pagaathan Pajknmar.Priority Inheritance and protocols:An Approach to Real-Time Synchronization .IEEE Trans .On Computer,(1990) 1175-1185
[4]Bil Lewis, Multithreaded Programming with Java Technology, Prentice Hall PTR, USADecember 01, (1999)
[5]Kleiman, Shah, Smaalders. Programming with Threads. Prentice Hall,USA,(1996)
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。