现在的位置: 首页 > 综合 > 正文

消息机制在软件设计中的应用

2013年01月12日 ⁄ 综合 ⁄ 共 1703字 ⁄ 字号 评论关闭

消息机制是个实用的东西,不知道是何人发明,个人见识较少,最早见于WIN32编程,关键的几句代码大约是:
while(GetMessage (&msg, NULL, 0, 0))
       
{       
    TranslateMessage (&msg) ;
       
    DispatchMessage (&msg) ;
       
}这就是WIN32消息机制的最核心了,虽然当时对这种颇为神奇的机制不甚了解,但却好奇,这里的消息从哪里来,TranslateMessage做了什么工作,为什么不能省略掉,DispathMessage又做了什么工作,消息又被送到哪里去了?如今基础稍微好点的VC程序员应该都能回答这几个问题,但是,微软设计出来的这个消息系统为什么会是看到的这个样子?有什么必然的原因么?

消息其实是对人类社会信息传递的一种极好的抽象,语言传递的是消息,信件传递的也是消息。

消息机制目前为止应用的最为广泛的领域估计依然是窗口系统,各种各样的GUI系统几乎都以自己的方式实现了对消息的处理,当然,不全是WIN32这个样子,如将回调函数直接注册到消息源通过回调实现响应的方法也被广泛采用。


                             图1

其实,类似WIN32这样的消息机制经过适当的裁剪或者改造,可以应用在许多不同的场合。

应用示例1:
   单片机系统,许多的单片机的运作逻辑都可以概括为响应事件的触发,并对输出做一定的调节,这个触发条件就可以被视为消息的输入,在具有LCD面板等人机界面的单片机系统中,基本上可以完全移植WIN32的消息机制进行处理而达到类似于合作式操作系统的效果。如下图:

                             图2

在如上图中,按键检测ISR,timer ISR,外部中断ISR为三个中断服务程序,在这三个ISR中只完成时间相关度相对高的操作,然后将事件消息放入消息队列,供主程序处理,单就这个处理方式来说,雷同于linux 中的tasklet机制,即将中断分为上下两部分,上部分处理硬件相关或者实时性强的操作,后半部分进行较大量的数据处理。在主程序的while循环中,不停的从消息队列获取消息,如有必要则对消息进行翻译或者整理,然后根据全局状态机或者GUI系统自己的父子窗口等机制确定消息流向,找到并调用相关的处理函数,通常,这里还需要一个Default_proc提供一些系统默认的消息处理方法。在如上的一个系统中,如果把每一个 wnd_proc看做一个任务的话,则任务切换的时刻发生在每个任务运行结束之时,或者说每个任务主动放弃执行权的时候,其效果也就类似于合作是调度的操作系统了,这样的实现方式对外部事件的响应能力明显强过典型的whie(1)结构,和实时操作系统相比,在基本不需要同步机制的情况下得到了有限的实时性,结构清晰,容易控制。

应用示例2:
 仔细分析图1会发现,整个系统其实是一个典型的“分----总------分”结构,两个“分”是说有多个输入,也有多个输出,一个“总”是说多个输入和输出都要服从一个统一的调配和管理。这样的系统恰好本人在最近遇到一个,该系统的要求如下:
1. 有多个触发输入,包括:移动侦测,RF位置触发侦测,遥控开关输入,外部数字触发,视频丢失
其中在RF触发侦测中还夹杂着灯光遥控功能,每一种输入要能单独使能。
2. 有多个触发输出,包括:JPEG抓拍,ASF录影,FTP录影传送,MAIL发送JPEG文件,MAIL发送纯文字信息,SMS短讯通知,PTZ摄像机定位,数字报警输出,声音报警输出,每一种输出要能单独使能,最好能针对每一种触发输入单独使能。
3. 整个系统要能整体开关。

分析整个系统,稍微改造一下图1的框架就可以应用于这个系统,具体实施过程如下:
1. 在各个触发检测线程内提交触发消息
2. 在消息提取循环中完成消息的翻译和对输入的信息的过滤,如:将提交的RF触发信号翻译为特定的触发位置,关闭整个系统等。
3. 为每个消息建立对应的处理函数和输出功能表,将触发输出函数动态的注册到相应的表中,实现触发输出的动态调整。
最终建立框架如下:

 

 

 

 

抱歉!评论已关闭.