事件和进程间的数据交换
//========================================================================
//TITLE:
// 事件和进程间的数据交换
//AUTHOR:
// norains
//DATE:
// Monday 13-July-2009
//Environment:
// WINCE5.0 + VS2005
//========================================================================
多线程的数据交流不难,毕竟是同属于一个进程,更为重要的是,代码还很可能同属于一个工程,基本上想怎么干就怎么干,大不了我用一个全局变量来做缓存来进行数据的交换。
但对于多进程来说,就没那么容易了。从代码的角度来说,多进程意味不同的工程,意味着不能简单通过全局变量来交流数据。试想一下,如果IE有一个全局变量g_iCurPage,你用什么方法才能得到该数据?因此,在多进程的情况下,多线程那一套就没辙了。
不过,如果只是交流数据,情况倒不显得那么糟糕。一般的流程无非就是:假设有两个,分别是进程A和进程B,当线程A改变某些数值时,它会通过发送相应的事件给进程B;进程B在获得该通知事件后,会采取一定的方式,读取进程A所改变的数值。
听起来是不是很简单?
在讨论这个问题之前,我们先假设这两个进程存在如下架构的代码。
从这段简单的代码之中,我们可以知道有这么两个难点,首先是进程A如何准备数据,其次便是进程B如何获取进程A准备的数据。
接下来要论述的方式,都是基于这个框架的两个难点来讨论。
一般的做法,无非有三种。
1).注册表
采用该方式后完善的代码如下:
该方法灵活性非常高,进程A如果想增加更多的通知数据,只需要简单地多设注册表项。而进程B可以不用管进程A设置了多少注册表项,只需要获取自己所需要的项目即可。
另外一个更为明显的优势在于,由于该方法是将数据保存于注册表,所以在进程B的运行是在进程A退出之后,进程B还能获取数据。甚至于,机器重启后,进程B依然能获取相应数据——前提条件是系统的注册表为Hive Registry。
如果说缺陷,确切地说是相对于另外两种方法而言,便是速度。因为期间会对注册表进行读写,所以速度会略有损失。如果对速度非常在意,那么该方法并不是最理想的。
2).内存印射
其实这种方式在我blog的另一篇文章《进程间的数据共享》(http://blog.csdn.net/norains/archive/2008/07/16/2663390.aspx)有提过,但为了本篇的完整性,在这里根据我们的论述框架重新来讨论一次。
原理很简单,进程A先调用CreateFileMapping开辟一个印射的内存区,然后往里面拷贝数据,最后通知进程B读取数据;进程B接受通知时,就直接调用memcpy从内存中获取数据。
该方法是最复杂的,两个进程不仅协同设置内存的大小(MEM_SIZE),还要设置同样的名称(MEM_SHARE_NAME),更要判断该内存是否能分配成功。相对的,灵活性也是最高的,只要以上问题协商解决,则什么数据类型都能传递,无论是DWORD,或是struct。当然,我们还是不能传递对象指针,因为简单地传递对象指针,则基本上都会引发内存访问违例的致命错误。
3).设置事件数据
相对于以上两种方式,该方式彻头彻尾只能属于轻量级。因为它方式最为简单,同样,所传递的数据也最少。
其原理很简单,进程A通过SetEventData设置和事件关联的数据,然后发送事件通知进程B;进程B接收到进程A的事件以后,则通过GetEventData来获取数据。根据该原理,则代码的样式可以如下:
该方式是最简单的,在传递DWORD长度类型的数据有得天独厚的优势,无论是速度还是简便性。但,也仅限于此,如果想采用该方式传递大小大于DWORD的数值,基本上会丢失精度,更不用说struct等结构体数值了。不过,这却是这三种方法之中,和事件联系最为紧密的。