[发明专利]一种通信设备软件子系统的消息调度方法

说明书

技术领域

本发明涉及通信设备软件子系统中消息的组织和调度，特别是涉及大型通信设备软件子系统的一种快速高效的消息调度方法。

背景技术

软件子系统要实现消息调度机制，需要维护一个消息映射表。按消息映射表的存储方式划分有两种，一种是如图1所示的存储位置离散的分布式消息映射表，另一种是如图2所示的存储位置相邻的集中式消息映射表。

一个分布式消息映射表可由n个被称为消息映射子表的数据结构组成，其中的消息映射子表可以是集中式消息映射子表，又可以是分布式消息映射子表。因为消息注册表是由程序员在编程时定义、输入数据并提供空间。因此，注册消息的接口数据在消息注册表中的相对位置是随机的。消息号与消息接口数据在消息注册表中的存储位置之间不存在确定的对应关系。如果不对消息注册表进行预加工，直接使用消息注册表的存储空间生成消息映射表，虽然能高效地利用存储空间，但是在消息调度程序定位消息在消息映射表中的位置时，唯一能使用的方法是对消息号进行逐一的匹配比较。查找的效率依赖于查找过程中所进行的比较次数。对一个规模为n的消息映射表，其平均查找长度为n/2。随着消息映射表规模的增大，软件子系统的调度效率急剧下降。采用上述方案的现有技术，如微软的Visual C++的MFC编程框架的消息映射处理机制，以及C和C++语言中编译器对Switch-Case语句的处理，均存在查找效率低的问题。

现在来说明微软的Visual C++的MFC编程框架的消息映射处理机制和C、C++语言中编译器对Switch-Case子系统的处理。从VisualC++提供MFC编程框架源码可以看到：MFC编程框架维护着一个分布式的消息映射表，当MFC的消息调度框架接收到一个消息时，在消息映射表中通过比较匹配查找到该消息对应的消息处理函数的入口，依此进行调度。位于消息映射表位置k的消息接口在调度时需经过k次比较。当消息规模不大或者系统对效率不敏感时，这种匹配方法是可以接受的。但是当系统要求高效率调度时，使用这种匹配方法显然是不合适。从编译后的汇编代码可以看到：C、C++语言的编译器把Switch-Case子系统认为是if-else的另一种表示方式。在这里存在一个抽象的分布式的消息映射表。系统通过比较匹配查找到相应的Case入口。当Case分支数不多时，系统调度的效率可以接受。但是当系统要求高效率调度时，使用这种匹配方式对Switch-Case子系统进行调度显然不合适。而且，以上两个例子还有一个不容易注意到的缺陷：即在实际应用中，每一个消息、每一个Case分支被使用的频率是不同的，因此，难以为每一个实际的系统提供最佳的调度策略。

在大型通信设备中还存在不同处理机之间的消息在交互时出现的字节顺序问题。如x86是低字节在低地址(小模式)，PPC是高字节在高地址(大模式)。将字节顺序问题完全交给应用层解决不仅程序效率低，而且容易出错。在以上描述中，x86表示Intel公司386、486、pentium系列的处理器芯片。PPC表示Motorola、IBM的PowerPC系列的处理器芯片。在这两种处理器芯片之间进行通信，就存在字节顺序问题。例如，对内存中按12 34 56 78方式排列的数据，x86认为是0x78563412，PPC则认为是0x12345678。传统的处理方法是将数据转换成网络序(大模式)进行交互，数据到达后，在各处理器上再根据自身字节顺序跟网络序的差异进行转换。因此当两边都是小模式处理器芯片时，就存在冗余的转换。而且程序员常常会因为遗忘对字节顺序的处理而导致数据辨认出错

发明内容

本发明要解决的技术问题是提供一种适用于大型通信设备软件子系统的快速消息调度方法，使其能对每一个实际的系统提供最佳的调度策略，达到时间上最优的调度效果，同时实现存储空间的高效使用。