[发明专利]一种消息处理方法及消息中心系统

说明书

技术领域

本发明涉及消息处理技术，更具体地，涉及一种消息处理方法及消息中心系统。

背景技术

商业软件的开发，大部分都需要有一些为其它模块提供服务的底层模块。这些底层模块由于实现的是一些通用功能，需要同时为几个高层模块提供功能，因此通常被设计成一种基于消息队列的框架。任何需要访问这些通用功能的高层模块，都可以通过发送消息并接受返回值来得到需要的服务。

这种构架的设计，一般是围绕消息队列来展开的：首先有一个消息队列，并对外暴露发送消息的API；然后实现一个负责维护并调度该消息队列的线程，该线程负责维护消息队列，并分发消息；最后是一系列处理特定消息的功能模块。消息由暴露给外层模块的API发送到消息队列，由调度线程接受消息，并分发给消息处理模块，然后由处理模块对不同消息进行处理，将处理结果返回给高层模块，这就是一个完善的基于消息队列的公用模块。为了实现这种模块的可扩展性，消息处理模块一般采取一种基于注册的设计，允许用户注册特定消息的消息处理函数。

Windows、Macintosh等操作系统都以线程(thread)作为系统的调度和运行单位，线程是比进程粒度更细的并行机制，它是程序内的动态执行流。1个任务内可以有多个线程并行运行，它们共享任务的所有资源，如内存空间。利用多线程可实现任务内的各子任务并行运行，提高事务处理效率。同任务内的多线程间可通过全局变量、文件、信号灯等方式实现同步。1个线程使自己处于睡眠(sleep)状态，等待所需要的事件发生，并由系统核心唤醒启动它。虽然此方式能实现同步多线程间的并行运行，但它不符合Windows程序结构，Windows系统的程序结构是以消息驱动方式构成的，主程序的消息循环部分从消息队列中获取与本程序有关的消息，并且送至相应的窗口过程函数，窗口过程函数负责接受并处理消息。如何在多线程间以消息传递方式来同步它们的并行运行，是值得讨论的问题。即每个线程都通过获取消息来驱动程序的运行，它们之间通过相互传递消息实现并行同步。当然实际中，由于对大量数据的共享，使得多线程间必须使用信号灯等同步方式来解决互斥问题。本文主要讨论关于多线程下消息处理的线程消息队列问题，线程管理问题，线程间消息传递问题以及所需的数据结构，最后还给出了线程消息处理模型。

Linux支持三种进程或线程之间的通信机制：消息队列、信号灯和共享内存。对这些资源的访问只能通过系统调用的方式进行。SystemVIPC对象权限都包含在一个ipcperm数据结构中，该结构包含了创建进程的用户和组标识符、针对这个对象的访问模式(属主、组和其他)和IPC对象的key。Linux支持两种key：公开的和私有的。如果key是公开的，那么任何进程只要通过了权限检查，就可以找到对应的系统IPC对象的引用标识符。在/usr/include/linux.ip.h中消息是在ipc/msg.c中实现，共享内存在ipc/shm.c，信号量在ipc/sem.c，管道在ipc/pipe.c中实现。信号量是一个可以用来控制多个进程或线程存取共享资源的计数器，经常作为一种锁定机制来防止多进程或多线程之间对临界资源或共享资源的访问冲突。目前多线程技术的发展已相当成熟，在许多的现代操作系统设计中均被引用，Linux中也有自己的线程管理机制，对于应用程序开发来说，使用多线程编程简化了编程的任务，改进了应用程序的效率。但是多线程之间的同步一直是Linux多线程编程中需要注意的问题。使用信号量原语可以有效地协调多线程之间对共享资源的访问，以保证程序运行结果的正确性。无疑，这对于编写Linux下的多线程应用程序有着重要的意义。

客户端程序设计中，随着软件复杂度的提升，模块的划分越来越明显，为了尽量降低模块之间的耦合度，需要一种消息注册和通知机制。传统的通知机制通常都是类似于Observer设计模式，通过函数回调来进行通知。

现有技术中的上述平台存在如下的主要缺点：

1.在比较大规模的项目中，各种消息可能来自不同的线程，模块之间的调用有不同的线程约束规则，线程同步等问题十分麻烦，容易带来各种问题；

2.传统的消息机制只能通过回调进行通知，无法将代码打包，不够灵活；

3.传统的消息机制消息携带信息类型和数量有限。

发明内容

为了克服现有技术中的上述缺陷和不足，本发明针对以上需求进行了设计，实现了一种基于主线程转发的消息中心系统。简化消息通知中的现成同步问题，对消息内容和类型没有限制。

本发明提供的一种消息中心系统，所述消息中心系统包括：