CN110532109B - 一种共享多通道进程通信内存结构和方法 - Google Patents

Abstract

在共享内存中建立通信通道区、通道状态区、任务队列区数据结构，实现不依赖特定进程创建、可复用和可并发通信的多个IPC通道；通过对通道状态分类和监测，实现通道空闲、占用和故障的识别，确保多进程通信稳定；通过共享内存传递“握手”信息和设置合理的报文结构，通信系统可以适应同步和异步通信，具备较高的通用性和灵活性。上述共享多通道进程通信内存结构和方法，可用于存在任意交叉进程间通信和同异步混合模式进程通信的系统，能有效降低其进程通信设计的复杂性。

Description

一种共享多通道进程通信内存结构和方法

技术领域

本发明涉及进程通信技术领域，尤其是涉及基于共享内存技术的多进程通信技术、内存结构和方法。

背景技术

在软件开发领域，进程间通信(IPC,InterProcess Communication)是一类基础技术，基于共享内存的进程通信是最快IPC方式。通常将共享内存划分为数个片段，形成数个通信通道，以提高通信的并发性。但现有技术中共享内存基本采用进程内创建，实质是将共享内存与进程绑定，并发性能提高仅限于绑定的进程范围。多进程交叉通信场景下，进程间呈现复杂的网状结构，若基于上述方法，必须为每一组通信进程创建一个共享内存实例，这不仅增加了系统的复杂度，也会造成系统稳定性下降。同时，由于进程间通信频率与信息长度因需求而定，即通信负载存在时间不确定性，若共享内存与进程绑定，事实上造成了系统资源利用的不平衡，在系统性能上形成“水桶效应”。

另一方面，进程通信“请求-响应”模式一般分为同步和异步两种。同步通信需要进程在发送完请求报文后进入等待状态，等待过程不会释放通信资源；若采用异步通信，通信过程会对资源进行释放和复用，但异步过程处理要相对复杂些。不同任务有针对性地采用同步或异步通信，有助于提高通信效率，但基于现有共享内存通信方式，通信效率提高被局限在几个通信进程之间，多进程交叉通信时更会增加实施复杂性，难以实现全局性的通信效率提升。

发明内容

本发明的目的在于克服上述共享内存通信技术缺陷，将通信通道全局共享，提高了IPC资源利用率，简化多进程交叉通信结构，均衡多进程通信负载，同时设计了通信“握手”方法、通信通道状态监测和复用机制以及同异步报文读写控制，确保通信稳定、灵活通用。

本发明具体技术方案如下：一种共享多通道进程通信内存结构，包括：通信通道区、通道状态区和任务队列区。

所述通信通道区是在共享内存中分配的二维数组空间，逻辑上形成多个等长度的数据读写通道(一维数组)。通信通道是随共享内存建立而自动创建，如果实现时采用一些技术手段，如动态链接库的共享数据段，可使创建过程不依赖具体进程。通信时首先分配通信通道，完成通信后通道可以再分配给其它进程使用，这一过程也可以在多个通道上同时进行。上述通信方式兼顾了各进程通信的频度和负载，有利于提高多进程通信整体性能。

通信通道具备多种状态，通信过程中需要管理和判别。本发明将通道状态分为三种：空闲态、占用态和故障态。所述空闲态是指通信通道可以直接分配使用的状态；所述占用态是指通信通道不能被分配的状态；所述故障态是指因进程异常导致没有更新通道状态，通信通道处于非正常占用的状态。故障态时通道上没有进程通信，通道也是可以分配使用的，但故障态是需要条件判断得出的。本发明中状态值取用易获取的简单类型数据，如0值表示空闲态，非0值表示占用态，故障态通过“阈值判定”方法来确定。

由于通信通道是共享的，通道状态值也应被进程共享。如果把通道状态值存储于各通信通道中，无疑增加了通道的读写次数，使得发生访问冲突的概率增加，影响通道读写性能。所述通道状态区是在共享内存中建立的一维数组空间，专门用于保存通道的状态值。多进程通信场景下通道状态值判断涉及锁内过程，为提高效率，将通道状态区逻辑上处理为首尾相连的环形数组，并设置一个变量CUR_INDEX来保存最近分配的通道号(也是通道状态数组下标)，通道分配时，可以利用此变量加快分配通道过程。

进程获取通道后，还需将通道号传递给响应进程，即所谓“握手”，随后双方才能在通信通道上读写报文。本发明通过设置任务队列区来实现这一功能。所述任务队列区是在共享内存中分配的二维数组空间，逻辑上将其处理为多个队列组，队列数量与通信进程数相等，即每一个进程都有属于自己的一个任务队列，同时在共享内存中设置保存各队列队头和队尾的数组。请求进程将通道号写入响应进程的任务队列，响应进程通过轮询自己的队列来获取通信通道号，从而完成与请求进程“握手”过程。为保障这一功能的实现，队列应与进程唯一对应，并保持稳定。具体实现时可以通过系统配置文件等形式固定进程队列编号，在进程启动时刻加载。

共享多通道的进程通信方法：

进程通信过程可以简单概括为“请求-响应”过程。共享多通道的进程通信过程包括：分配通信通道、初始化读写事件、添加通道号到任务队列、读任务队列、发送请求报文、响应请求、发回响应报文、释放通道等。

通道分配是每一个进程通信的起点，请求进程通过扫描通道状态区，识别通道状态，获得通信通道。根据概率分析，距离当前时间最远时刻分配的通道处于空闲态的可能性最大。因此将当前通道状态数组下标保存到共享变量CUR_INDEX中，通道分配时，通过对CUR_INDEX循环使用“加1取模”方法逐个获得预选通道。考虑到存在无通道可分配的情况，当循环次数达到一定限值时返回失败。

通道分配过程可概况为如下几步：

步骤11：初始化循环次数变量i＝0；

步骤12：计算CUR_INDEX＝(CUR_INDEX+1)％N(N为通道数)获得预选通道号；

步骤13：若预选通道为空闲态或故障态，则更新其为占用态，并返回CUR_INDEX，否则执行步骤14；

步骤14：若循环次数大于限值，返回失败；否则计算i＝i+1，执行步骤12。

另外，处于故障态的通道也是可分配的，因此分配通道也是一个修复通道的过程。通道空闲状态值一般容易识别，如0值，占用态和故障态均为非0值，而且故障态值就是超过阈值的占用态值，因此通道状态值在正常通信过程中也需要更新。读写通道的过程事实上是在内存中传递数据，时间非常短暂，此时没有必要更新通道状态值，更新通道状态反而会降低通信效率。相比之下进程等待响应的时间可能就会漫长得多，此过程中就需要定时更新通道状态值，否则在其它进程分配通道时容易造成通信混乱，而此时该通道上的请求进程处于等待状态，通过较小的时间间隔更新通道状态值不会对通信效率产生影响。

进程通信“请求-响应”模式(即通信模式)分为两种：同步通信模式和异步通信模式。如果采用同步通信模式，整个通信过程只有一次通道分配过程，在等待响应报文的时段里通信通道处于无数据传递、也不能分配的空占状态。如果采用异步通信模式，进程发送完请求报文后需释放通信通道，在发送响应报文时需重新分配通信通道。虽然异步通信模式有两次通道分配过程，异步通信模式对通信通道的利用效率相对高些，毕竟分配通道和读写通道的过程都非常短暂，响应请求的处理过程相对漫长得多。但异步通信模式中，请求进程对报文的处理要复杂些，如请求报文必须包含进程队列号(识别请求的进程)和任务特征码(识别请求的任务)。

如前所述不同通信模式的报文结构是有差异的。因此读写报文前就要明确具体的通信模式。本发明中，请求进程在添加通道号时对通道号作相应的处理，如异步模式时取通道号+1后的负值(避开0值)，响应进程在读队列时根据数据的正负和约定算法很容易得到通道号和通信模式。除此之外，本发明将报文结构分为摘要和内容两部分。摘要是报文内容的概要信息，同步通信时摘要包括：字节数、同步超时阈值，异步通信时摘要包括：字节数、任务队列号和任务特征码。其中字节数是内容长度，不包括摘要。每次写报文时仅第一次写入时包含报文摘要部分，并且每次写入都最大化写满通信通道，读取时可以通过报文字节数和通道容量判断报文是否发送完毕。如，设报文字节数L，通道容量W，当前已写入字节数LW，摘要字节数S，当LW>0时，S＝0，则本次写入的字节数为min{W，L-LW-S}；若当前已读取的字节数为LR，当LR>0时，S＝0,则本次读取的字节数为min{W，L-LR-S}。异步通信模式下，发送响应报文必然也是异步模式，原请求进程必须给出自己的任务队列号以及任务标识(任务特征码)，以确保响应进程能够按异步模式有效发回响应报文，同时进程也需要通过与自己的任务队列号比较识别出所读取的是请求报文还是响应报文，或者是自己哪一个请求的响应。任务队列号和任务特征码仅用于异步通信模式，同步通信模式时报文摘要中除字节数外，还有同步超时阈值，进程在发回同步响应报文前将自己处理任务的时长与此值比较，若超过此值，则放弃发送。

共享的通信通道内存结构具备通用性和可并发性，即通道容量与进程、报文长度没有关联性，通信双方可能在一个通道上多次收发报文，与此同时在多个通道上也可能都存在通信。这些都涉及通道控制信号及信号传递，而且必须满足每通道独立和跨进程应用。为此，本发明为每个通道设置了独立的命名事件(EVENT)，如读写事件、停止事件，以控制多通道并发和报文交替读写过程。事件的创建、句柄关联和状态改变等操作均属于操作系统的内核过程，但执行速度有很大差异。具体而言，句柄关联和状态改变(如激活事件)速度很快，而创建一个新事件却相当耗时，由此可见每次通信时创建事件会严重影响通信效率。一种解决方式就是在进程启动时一次性创建所有的事件，并保持其生命期直到进程退出，在使用事件时通过关联句柄等手段获得事件句柄，这样可以有效降低事件初始化时间。而通信通道数量有限，相对于通信的进程而言，事件实例占用的内核资源基本可以忽略。

进程通信过程发生故障不可避免，如进程异常退出、任务超时等。本发明中对通信通道异常占用(故障态)有相应处理措施，但一般宜采用保守的判定方法(如以时间值判断，并采用较大的超时值)，这是因为很难确定通信双方是否都放弃了通信通道。极限情况下，容易造成一段时间内可分配的通道数量下降。为此，本发明为每个通信通道设置独立的停止事件，通信过程中一方主动退出时激活该事件，另一方检测到有停止事件后置通道为空闲态，主动释放通信通道，以此避免上述极限情况发生几率。

对于进程发送报文，通信过程包括如下步骤：

步骤S01：申请通信通道，若成功则初始化此通道的读完成事件、写完成事件和停止事件(均为非激活状态)，否则返回失败；

步骤S02：通道号添加到响应进程任务队列，若采用异步通信模式需对通道号处理后再写入队列；

步骤S03：设置变量WR_SIZE，发送报文时用于记录剩余字节数，读取响应报文时用于记录已读字节数；

步骤S04：写入报文：首次写入时先写摘要信息再写报文内容，更新WR_SIZE值；激活写完成事件；

步骤S05：如果报文已发送完成(WR_SIZE＝＝0)：若通信是异步模式，返回成功(通道由响应进程释放)，若通信是同步模式执行步骤S07；如果报文没有发送完成(WR_SIZE>0)，执行步骤S06；

步骤S06：等待读完成事件(由响应进程激活)，等待过程若发生停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)并返回失败，否则执行步骤S04；

步骤S07：等待写完成事件(同步通信等待响应进程写入报文)，等待过程若发生停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)，返回失败；

步骤S08：读取报文，首次读取时处理摘要信息，并更新WR_SIZE值；若WR_SIZE等于报文字节数，置通道空闲态，返回成功；否则激活读完成事件，执行步骤S07。

对于进程接受报文，通信过程包括如下步骤：

步骤R01：读取任务队列，获得通道号，如果通道号为负值需按约定算法计算得到正确通道号；

步骤R02：关联或打开通道上的事件句柄(不改变事件状态)；设置变量RD_SIZE保存报文剩余字节数；

步骤R03：等待写完成事件，等待过程若发生停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)，返回失败；

步骤R04：读取报文，首次读取时保存摘要信息，更新RD_SIZE值；

步骤R05：若RD_SIZE等于报文字节数，置通道空闲态，返回成功；否则激活读完成事件，执行步骤R03。

相对于现有技术，本发明的改进效果如下：

1)在共享内存中建立通信通道区、通道状态区、任务队列区数据结构，可实现不依赖特定进程创建、可复用和可并发通信的多个IPC通道，有利于提高进程通信性能；

2)进程通信通道具备检错、自修复能力，局部通信故障不影响通道的重复使用；

3)通过共享内存传递“握手”信息和设置合理的报文结构，通信系统可以适应同步和异步通信，具备较高的通用性和灵活性。

附图说明

图1是共享多通道进程通信系统结构；

图2是逻辑上为环形数组的通道状态区结构；

图3是通信通道区内存结构；

图4是任务队列区内存结构。

具体实施方式

共享内存属于操作系统内核，不同操作系统上实现方式有所区别。在微软公司windows平台上，可利用内存映射或者动态链接库的共享数据段等技术实现。对于内存映射技术，windows系统提供了允许应用程序把文件映射到一个进程的函数(CreateFileMapping)，若在函数调用时指明文件句柄为系统预置的无效句柄INVALID_HANDLE_VALUE，则无需实质上的磁盘文件，系统会自动利用虚拟内存的页面文件创建可共享的内存区块。其它进程通过调用MapViewOfFile函数获得共享内存块的起始地址。内存映射获得的内存块是一段连续空间，一般使用时还需将其映射到特定的结构化数据空间。在动态链接库技术中，系统提供data_seg指令，可以指定共享数据段。共享数据段内允许一个或多个基本数据类型定义的变量或数组，数据结构清晰，而且所定义的变量或数组均存放于内存中，速度更快，但动态库要增加导出函数才可以操作共享数据段内的变量和数组。

下面以动态链接库创建共享多通道进程通信方案为例，说明本发明的实施过程。

共享多通道进程通信内存结构的创建：

利用动态链接库的共享数据段，定义多个可共享数据结构，包括说明书中描述的内存区域：通信通道区、通道状态区和任务队列区。

所述通信通道区是在动态链接库的共享数据段内定义的字符型二维数组，其中每一维数组作为一个共享的通信通道。

所述通道状态区是在动态链接库的共享数据段内定义的一维整型数组，逻辑上为一环形结构，元素个数与通道数相等，用于存储通信通道的状态值。通道状态分为空闲态、占用态和故障态。所述空闲态是指通信通道可以直接分配使用的状态，用0值表示；所述占用态是指通信通道不能被分配的状态，用非0值表示；所述故障态是指因进程异常导致没有更新通道状态，通信通道处于非正常占用的状态。事实上，故障态就是非正常的占用态。为诊断方便，使用C库的time函数返回值作为占用态值，通道分配时利用时间阈值来判断通道故障态。这也是选择数组类型为整型的原因。为便于通道分配时检索通道状态值，共享数据段内还定义了整型变量CUR_INDEX用于保存当前检索的位置，由于通道状态区数组与通信通道一一对应，CUR_INDEX也可当做通道号。

所述任务队列区是在动态链接库的共享数据段内定义的二维整型数组，其每行的一维数组作为一个队列，队列的数量不少于通信进程的个数，保证每一个通信进程拥有一个队列。进程获得通道后，将通道号写入响应进程的任务队列，响应进程通过轮询自己的队列来获取通信通道号，从而完成与请求进程“握手”过程。为保障这一功能的实现，队列应与进程唯一对应，并保持稳定。实现时可以通过系统配置文件等形式固定进程队列编号，在进程启动时刻加载，如果不考虑灵活性，也可以直接固化到代码里。为配合队列操作，同时在共享数据段中设置保存各队列队头和队尾的数组。

按动态链接库技术规范，共享数据段内的任何变量或数组必须给出初值，这样动态库第一次被加载到进程地址空间时，会按代码给出的初值执行初始化工作，此后任何动态库加载过程均不会初始化数据。这表明利用动态链接库技术创建共享多通道内存结构的同具体进程无关。

动态链接库共享数据段实现的示例代码如下：

#define COMMU_COUNT 128//通道数

#define COMMU_BUFSIZE 512//通道容量

#define PROCESS_COUNT 10//进程数

#define QUEUE_SIZE 512//队列深度

#pragma data_seg("36025D5")//预编译指令，指明数据段

char CommuBuf[COMMU_COUNT][COMMU_BUFSIZE]＝{0}；//通道区

__int32CUR_INDEX＝0；//当前状态区下标

long CommuStatus[COMMU_COUNT]＝{0}；//通道状态区

__int32ProcTask[PROCESS_COUNT][QUEUE_SIZE]＝{0}；//任务队列

__int32ProcHead[PROCESS_COUNT]＝{1,1,1,1,1,1,1,1,1,1}；//队列头

__int32ProcTail[PROCESS_COUNT]＝{0}；//队列尾

#pragma data_seg()

#pragma comment(linker,"/SECTION:36025D5,RWS")。

进程通信中事件(EVENT)的创建和管理：

共享的通信通道内存结构允许通信双方在一个通道上多次收发报文，以及在多个通道上并发通信。控制通道上读写的信号系统必须满足能够跨进程使用的要求。为此在每个通信通道都设置独立的命名事件(EVENT)来控制跨进程的读写过程。此外，通道状态区、任务队列区的操作也同样设置独立的命名事件实现读写控制。共享多通道进程通信中需要设置的命名事件数量如下：

通信通道区，每通道3个：读完成事件、写完成事件和停止通信事件；

通道状态区，1个：读写事件；

任务队列区，每队列1个：读写事件。

按windows API规范，事件这样的系统内核资源是通过句柄(HANDLE)的方式获得引用，而句柄是不能被多进程共享的，只能通过CreateEvent、OpenEvnet之类的函数创建或获得事件的实例。多次调用CreateEvent创建同名事件，事实上是创建同一事件的多个实例，可共享事件状态。使用OpenEvent可以通过名称关联一个已经存在的同名事件(不同句柄)，并共享事件状态。而事件状态可以通过句柄来设置。操作系统保证对事件操作的原子性。

事件的第一次创建(调用CreateEvent)相当耗时，而关联句柄和改变事件状态相对快很多。若在每次操作时创建事件，既要准备名称(字符串)，又要创建事件实例，会对运行速度造成很大影响，同时也是低效的编码方式。比较好的办法是利用面向对象技术，将名称和事件分别封装，并定义全局对象进行管理。这样在进程启动时一次性创建全部对象，进程退出时自动清除对象。运行时，在可以直接使用事件的场合，通过索引(通道号、队列号)直接获得事件句柄，在需要通过名称关联事件的场合，也可以先通过索引获得字符串，再调用OpenEvent(获得一个新句柄，但更快)关联事件实例。而每一个通信通道、队列的事件都是独立的，操作上述对象也不会涉及锁内过程。实践证明这样操作速度极快，虽然进程在整个生命期内一直占用内核资源，但通信通道数量有限，相对于通信的进程而言，事件实例占用的内核资源基本可以忽略。

以下示例代码使用一个固定串和数字组合的事件名称类：

以下是事件封装类的示例代码，其中利用了名称封装类对象：

依照示例代码定义名称和事件的全局变量，如定义读完成事件及其名称的全局变量：

EventName g_RFName(COMMU_COUNT,"read_fin_")；

EventObj g_RFEvent(g_RFName)；

若使用通道K的读完成事件句柄，可以通过g_RFEvent[K]直接得到；若通过名称获得事件句柄，可以调用OpenEvent(0,0,g_RFName[K])得到。

通信通道分配的实施过程：

通信通道分配是每一个进程通信的起点，请求进程通过扫描通道状态区，识别通道状态，获得通信通道。识别通道状态过程也是对空闲态和故障态通道的复用过程。三种通道状态值：空闲态为0值；占用态为整型值，写入时调用C库函数time获取；故障态为整型值。其中，占用态和故障态通过时间阈值来判断的。

通信通道分配属于锁内过程，因此分配过程应尽可能快速完成。具体实施时通过两个方面的措施来实现快速分配的要求：一是提高预测命中率，二是限定循环次数。根据概率分析，距离当前时间最远时刻分配的通道处于空闲态和故障态的可能性最大。因此将当前状态区下标保存到共享变量CUR_INDEX中，通道分配时，通过对CUR_INDEX循环使用“加1取模”方法逐个获得预选通道，当循环次数达到一定限值时返回失败。

通道分配过程的伪代码表示如下：

共享多通道进程通信实施过程：

进程通信过程总体上包含三个过程：双方“握手”，双方传递报文，释放通道。每一步的具体细节与通信模式关系密切。

“握手”过程有两个任务：传递通道号和传递通信模式。具体实施时，根据通信模式将通道号作不同的处理，以达到仅执行一次添加任务队列就可以完成上述两个任务的目的。若提交处理的通道号为K，处理的伪代码如下：

if同步通信模式

return K

else

return–(K+1)

当响应进程读取任务队列时，容易从数据正负和简单的换算就可以获悉通道号和通信模式。

报文结构分为摘要和内容两部分，其中摘要是报文内容的概要信息。异步通信时摘要包括：字节数、任务队列号和任务特征码，同步通信时摘要包括字节数和同步超时阈值。字节数是指内容的字节数，不包括摘要。同步超时阈值用于进程发回同步响应报文前检查任务是否已超时，若超时则放弃发送。任务队列号用于标识请求进程，任务特征码用于请求进程内标识任务，两者均由响应进程随响应报文原样发回，进程通过与自己的任务队列号比较来区分读取的报文是请求还是响应，或者是自己哪一个请求的响应。每次写报文时仅第一次写入时包含报文摘要部分，每次写入都最大化写满通信通道，响应进程可以通过报文字节数和通道容量判断报文是否发送完毕。

同步通信模式时，整个通信过程只有一次通道分配过程，请求和响应的报文在同一个通道上完成，在响应进程处理请求任务的过程中，请求进程需等待一段时间，可能等待时间长于判断故障态的阈值，这就需要请求进程定时更新通道状态值，更新时间间隔还要小于阈值，如阈值取5000毫秒，更新时间取2000毫秒，以免通道分配时产生误判。

通信过程常见的故障就是超时，如等待事件(EVENT)超时、等待报文超时等。具体实施时，除了科学确定时限值外，也需要作异常处理措施。为此作如下规定：通信过程中，主动退出时激活该通道的停止事件，不释放通道；检测到有停止事件时，释放通信通道(置空闲态)。无论同步还是异步通信，交替读写通道的过程都是非常短暂的，超时限值设置较小值，如200毫秒。如果此时发生超时是无法判断对方实际状态的，所以保守做法是置停止事件、不释放通道，这样即使双方都不响应停止事件、释放通道，通道分配时也是可以通过阈值检查来复用通道。

对于进程发送报文，通信过程描述如下：

步骤S01：获得通信通道K，若成功则初始化此通道的读完成事件、写完成事件和停止事件均为非激活状态，否则返回失败；

步骤S02：如果是同步通信，K值添加到响应进程任务队列，否则将-(K+1)值添加到响应进程任务队列；

步骤S03：设置变量WR_SIZE，发送报文时用于记录剩余字节数，读取报文时用于记录已读字节数；

步骤S04：写入报文：首次写入时先写摘要信息再写报文内容，非首次写入仅写报文内容；更新WR_SIZE为报文内容剩余字节数；激活写完成事件；

步骤S05：当WR_SIZE＝＝0时，若通信是异步模式，返回成功(通道由响应进程释放)，若通信是同步模式执行步骤S07；当WR_SIZE>0时，执行步骤S06；

步骤S06：等待读完成事件(由响应进程激活)，等待过程若收到停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)并返回失败，否则执行步骤S04；

步骤S07：等待写完成事件(同步通信等待响应进程写入报文)，等待过程若发生停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)，返回失败；

步骤S08：读取报文，首次读取时处理摘要信息，并更新WR_SIZE为已读取报文内容字节数；若WR_SIZE等于报文字节数，置通道空闲态，返回成功；否则激活读完成事件，执行步骤S07。

对于进程接受报文，通信过程描述如下：

步骤R01：读取任务队列，获得通道号K，如果K<0，则K＝-K-1；

步骤R02：设置变量RD_SIZE＝0；获得通道K上的读完成事件、写完成事件和停止事件句柄(不改变事件状态)；

步骤R03：等待写完成事件，等待过程若发生停止事件，置通道为空闲态，返回失败；如果等待超时，激活停止事件(不处理通道状态)，返回失败；

步骤R04：读取报文，首次读取时保存摘要信息，更新RD_SIZE为读取的报文内容字节数；

步骤R05：若RD_SIZE等于报文字节数，置通道空闲态，返回成功；否则激活读完成事件，执行步骤R03。

需要说明的是上述实施例，并非用来限定本发明的保护范围，在上述技术方案的基础上所作出的等同变换或替代均落入本发明权利要求所保护的范围。

Claims (3)

1.一种内存装置，用于进程共享多通道进行通信，其特征在于，包括通信通道区、通道状态区和任务队列区，所述通信通道区是在共享内存中分配的一段二维空间，其中每一行为一个通信通道，各通信通道相互独立，通道上的读写由此通道上的读写事件控制；所述通道状态区是在共享内存中分配一段一维空间，其中每一个单元存储了通道状态，且与通信通道一一对应，将通信模式分为同步通信模式和异步通信模式；所述同步通信模式是进程在同一个通信通道发送请求并等待、接受响应，所述异步通信模式是进程发送请求后释放通道，响应进程完成请求任务后再发送响应；异步通信有两次通道分配过程，同步通信仅有一次，所述通信模式还包括通信“握手”方式：同步通信时，将通道号K添加到响应进程任务队列，异步通信时，将通道号K按-(K+1)值添加到响应进程任务队列；所述进程在读取任务队列时，按对应逻辑计算获得正确的通道号和通信模式。

2.根据权利要求1所述的内存装置，其特征在于，还设置了报文结构包含摘要和内容两部分，摘要是报文内容的概要信息，同步通信时摘要包括：字节数、同步超时阈值，异步通信时摘要包括：字节数、任务队列号和任务特征码。

3.根据权利要求2所述的内存装置，其特征在于，还包括了写入和读取通信通道的方式：仅第一次写入时包含报文摘要，并且每次写入都最大化写满通信通道；读取时通过摘要中的字节数和通道容量判断是否已经读完。

Images