一种共享内存管理方法、装置及系统与流程

本申请涉及计算机技术领域，尤其涉及一种共享内存管理方法、装置及系统。

背景技术：

多进程软件系统中通常需要将数据存储在共享内存中，进程通过访问该共享内存读取数据进行相应处理；而共享内存需要经过创建、进程间流转、回收等处理，因此，多进程软件系统中需要对共享内存进行管理。

传统的多进程软件系统中采用的共享内存管理方式为：预先根据业务规定的数据流转路径，设置实现该业务的各个进程之间的调用关系；当该业务下有待处理数据时，由第一个进程根据待处理数据的大小临时申请一个共享内存，然后第一个进程根据进程调用关系调用下一个进程访问该共享内存进行数据处理，直到数据处理完毕时，系统才释放掉该业务的共享内存。

对于多进程软件系统而言，需要针对每种业务创建实现该业务的进程以及设定各个进程之间的调用关系，当系统内业务种类较多时，需要创建大量的进程，进程之间的调用增加了进程的耦合性，系统适用性较低；并且在业务量较大的情况下，系统可能会出现超负荷的问题。

另外，在实际应用中，系统中的已有业务会根据实际需求而经常性发生一些改变，则开发人员就需要针对性地调整各个进程以及各个进程的调用关系，代码调整的工作量繁琐且巨大，则很难保证业务调整响应地及时性。

技术实现要素：

为解决现有存在的技术问题，本申请提供了一种共享内存管理方法，以期降低进程间相互调用的耦合性，并提高系统适用性。

本申请还提供了一种共享内存管理装置和系统，用以保证上述方法在实际中的应用及实现。

在本申请第一方面提供了一种共享内存管理方法，所述方法包括：

针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；

当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

本申请第二方面提供了一种共享内存管理装置，所述装置包括：

控制管道创建及节点挂载模块，用于针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；

数据处理模块，用于当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

本申请第三方面提供了一种共享内存管理系统，所述系统包括：

至少一个处理器和至少一个存储器，所述至少存储器中存储有可操作指令，所述至少一个处理器读取并执行所述可操作指令；

所述可操作指令，至少包括：

针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；

当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

与现有技术相比，本申请提供的技术方案具有如下优点：

在本申请的技术方案中，考虑到多进程软件系统中业务处理是依赖于进程间数据处理来实现的，提出了针对一种业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；这种将进程功能节点化的方式，可以使不同的业务公用同一进程的不同功能节点，更加灵活地使用已有进程；再者这种节点挂接方式，方便根据业务需求动态调整数据处理流程，能够提高系统适用性。

当该业务有数据需要处理时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内容，以实现对所述待处理数据的处理。该方法不需要依赖进程间的直接地调用，而是通过业务的控制管道控制节点实现对数据的处理，从而能够降低进程间的耦合性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的一种共享内存管理方法的流程图；

图2为本申请提供的不同进程功能节点化的结果示例图；

图3为本申请提供的针对一个业务构建的控制管道和缓存池的结构示意图；

图4为本申请提供的一种共享内存管理装置的结构图；

图5为本申请提供的一种共享内存管理系统的结构图。

具体实施方式

本申请的目的在于提供应用于多进程软件系统中的一种共享内存管理方法及装置，以提供一种新的共享内存管理方式，降低进程间的耦合性，提高系统适用性，进一步地还可以减小系统内存激增现象。

本申请通过针对业务建立对应控制管道机制来管理共享内存，利用挂接在控制管道上的、实现待处理业务的源节点、一个或多个中间节点、目的节点形成数据单向控制链路以控制共享内存的创建、传输、回收。这些节点都是不同进程所承载的功能节点，即，在本申请中对进程作了功能节点化处理，使得一个进程可以向不同的业务提供功能节点的方式，实现对不同业务的数据处理。从而，在本申请中针对业务的数据处理时，就通过所述控制管道控制挂载在控制管道上的节点进行相应的数据处理，以完成对该业务下的待处理数据的处理。这种方式不再单纯地依赖进程之间调用，而是利用控制管道实现共享内存和数据的传输，从而能够降低了进程间相互调用的耦合性，提高系统的适用性。

为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参阅图1，图1为本申请提供的一种共享内存管理方法实施例1的流程图，如图1所示，该方法可以包括以下步骤：

步骤101：针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点。

在本实施例中，业务是指基于多进程的数据处理业务；但在本实施例中，对业务所属的具体行业，业务的具体内容，业务的具体形式均不作限制，比如，基于多进程的手机3G增值业务，基于多进程的银行日终结息业务等，任何一种需要多进程实现的数据处理业务都适用本申请实施例的方法。

在本实施例中，针对一种业务创建一个控制管道，则不同的业务均有各自对应的控制管道，业务与控制管道之间成一一对应关系。

在实现时，可以通过以下方式为业务创建控制管道：

根据业务的数据处理流程实例化一个对象，将该对象称为控制管道，该对象包括：节点实例化地址的链表和节点间回调地址的回调接收器；在创建该对象时，可以清空保存节点实例化地址的链表，以便在节点挂载时存储节点实例化地址，并将节点回调接收器地址传递给节点。

比如，针对业务1创建了控制管道A，针对业务2创建了控制管道B，针对业务3创建了控制管道C，则相成以下对应关系：

业务1与控制管道A成一一对应关系；

业务2与控制管道B成一一对应关系；

业务3与控制管道C成一一对应关系。

在上述步骤101中，将实现所述业务的节点挂接在所述控制管道，其实现过程是，系统的应用层根据业务需求将与该业务相关的进程中的功能节点依次挂接在与该业务对应的控制管道上。在一个进程被功能节点化处理后，其可能包括一个或多个功能节点，该功能节点可以是源节点、中间节点、目的节点。

在实现时，可以通过以下方式实现进程的功能节点化处理：

当一个进程参与某个业务的数据处理流程时，该进程就创建一个处理节点，并将该处理节点的数据处理流程封装在节点处理函数中，该处理节点通过该节点处理函数实现其功能，则该处理节点就是该进程的一个功能节点。

例如，一个进程可能包括一个或多个源节点，也可能包括一个或多个中间节点，也可能包括一个或多个目的节点；一个进程也可能包括：一个或多个源节点、一个或多个中间节点、一个或多个目的节点的任意组合。

以图2为例，对一个进程包含功能节点的情况进行示例化说明。

在图2中，进程1包括：两个源节点S1和S2；

进程2包括：一个目的节点T1；

进程3包括：三个中间节点I1、I3和I4；

进程4包括：一个中间节点I2；

进程5包括：一个源节点S3和两个目的节点T2和T3。

其中，源节点是指用于完成数据初始化工作的功能节点；中间节点是指对数据作处理的功能节点；目的节点是指使用中间节点处理后的数据的功能节点。

以图2为例，对上述步骤101进行示例性说明。

针对业务1构建控制管道A，然后根据业务1的数据处理流程，确定与其业务相关的功能节点分别是进程1中的一个源节点S1和进程2中的目的节点T1；将节点S1和T1按照顺序依次挂接在控制管道A上。

针对业务2构建控制管道B，然后根据业务2的数据处理流程，确定与业务2相关的功能节点分别是进程1的一个源节点S2、进程3的两个中间节点I1和I3、进程4的一个中间节点I2，以及进程5的一个目的节点T2；则将节点S2、I1、I2、I3以及T2按照顺序依次挂接在控制管道B上。

针对业务3构建控制管道C,然后根据业务3的数据处理流程，确定与业务3相关的功能节点分别是进程5的源节点S3、进程3的中间节点I4以及进程5的目的节点T3；则将节点S3、I4以及T3按照顺序依次挂接在控制管道C上。

其中，挂接操作的具体实现过程如下：

根据所述业务的数据处理顺序，将源节点、中间节点、以及目的节点的实例化地址依次存储至所述控制管道维护的节点链表中，并使用回调机制与所述控制管道建立通知关系。

例如：源节点在挂接时创建通知信号，并将实例化地址存储至控制管道维护的节点链表中。在后期，针对该业务下的待处理数据，源节点根据业务需求初始化共享内存，启动共享内存在控制管道上的传输。

中间节点：中间节点挂接时创建通知信号，并将实例化地址存储至控制管道维护的节点链表中。同时，从控制管道获取上一个节点(“上一个节点”可能是源节点，也可能是中间节点)通知信号信息(如信号名称)来创建等待信号，启动数据处理线程，使用等待信号挂起线程。在后期，针对该业务下的待处理数据，中间节点接收上一个节点通知后，再进行数据处理，处理完毕后再通知下一个节点继续进行数据处理。

目的节点：目的节点挂接时从控制管道获取最后一个中间节点通知信号信息(如信号名称)来创建等待信号，启动数据处理线程，使用等待信号挂起线程。在后期，针对该业务下的待处理数据，目的节点接收最后一个中间节点通知后，拷贝数据处理结果，向应用层提供数据，并通知控制管道处理完毕。

经过上述步骤101的处理，就针对业务构建好其对应的数据处理链路。当该业务下有数据需要处理时，则直接利用该数据处理链路进行处理即可。

接下来，步骤102描述的就是利用该数据处理链路处理数据的过程，在该过程中实现对共享内存的创建和传输等处理。

步骤102：当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

在实现时，步骤102可以包括：

通过所述控制管道控制所述节点中的源节点向系统申请共享内存；以及，

通过所述控制管道控制所述节点中的源节点对申请到的共享内存进行数据初始化，并控制所述节点中的源节点和中间节点通过内核事件信号通知机制向所述节点中的下一个节点传递所述共享内存和处理后的数据，以完成对所述待处理数据的处理。

可以理解的是，当接收到所述业务的待处理数据时，通过所述控制管道控制所述源节点向系统申请共享内存，并初始化数据，通过内核事件信号通知机制传递共享内存数据至中间节点、目的节点，以使所述中间节点依次完成数据处理以及目的节点完成数据使用。

即，当系统接收到该业务下的一条待处理数据时，就由该业务对应的控制管道上的节点来接收该条待处理数据，并对该条待处理数据进行相应处理。具体处理过程如下：

源节点在接收到待处理数据时，根据待处理数据大小向系统申请共享内存，申请到共享内存之后，初始化数据，完成数据初始化之后，源节点将节点序号和共享内存地址反馈给所述控制管道，所述控制管道设置下一个节点的共享内存地址，激发源节点通知信号；

中间节点等待的源节点通知信号被激发后，进行数据处理，处理完成后将节点序号和共享内存地址反馈给所述控制管道，所述控制管道设置下一个节点的共享内存地址，激发中间节点通知信号，通知下一个中间节点进行数据处理，直到最后一个中间节点通知目的节点完成数据使用。

本申请发明人进一步分析发现：传统的多进程软件系统采用的共享内存管理方法，每一次处理数据，都需要临时申请一个共享内存，使用完毕后再释放掉该共享内存，这样，频繁动态申请和释放内存，容易造成系统内存激增现象，一定程度上影响系统的性能。

为了进一步解决现有技术中存在的频繁动态申请和释放内存，容易造成系统内存激增现象的问题，本申请还提供了对应的解决方法，该方法具体是在上述图1所示方法的基础上，还增加如下步骤：

针对所述业务创建缓存池，根据所述业务的需求向系统申请多个共享内存，在所述缓存池中存储所述多个共享内存的地址；

则所述待处理数据所使用的共享内存是由所述节点中的源节点从所述缓存池中申请的一个共享内存。

相应地，上述步骤102中的所述控制管道控制所述节点中的源节点向系统申请共享内存，包括：

通过所述控制管道控制所述源节点从所述缓存池中获取可用的共享内存的地址。

所述缓存池可以使用链表的方式来存储申请到的多个共享内存的地址，利用链表存储方式能够快速查看、定位共享内存地址。

即，在所述缓存池中存储所述多个共享内存的地址，可以包括：

在所述缓存池中使用链表存储所述多个共享内存的地址。

这里需要说明的是，本申请实施例在实现创建缓存池时，可以采用创建控制管道包含缓存池的方式，则在创建控制管道时，通过调用缓存池接口方法初始化缓存池，即申请共享内存块。在这种情况下，则节点就可以直接从控制管道就可以申请共享内存。

当然，在实现创建缓存时，也可以独立于控制管道，创建一个缓存池，但控制管道需要维护缓存池的实例化地址，以便通知节点从该缓存池中申请共享内存。为了方便本领域技术人员更清楚地理解上述方法，下面结合图3对上述方法的实现原理进行解释说明。

如图3所示，针对一个业务构建控制管道和缓存池，控制管道上挂接有实现该业务的各个节点；缓存池向系统申请多个共享内存，源节点在需要进行数据处理时，直接从缓存池中获取可用的共享内存，再通过控制管道传递该共享内存和处理后的数据，各个中间节点依次对接收到的数据进行相应处理，直到目的节点处理完毕后向缓存池返回该共享内存。

另外在上述图1所示方法的基础上，所述方法还可以包括以下步骤：

当所述待处理数据处理完毕时，回收使用后的共享内存。

即，目的节点完成数据使用时就标志着所述待处理数据处理完毕，即，在目的节点在完成数据使用时，通知控制管道此次数据处理已经完成，则系统直接回收目的节点使用后的该共享内存。

进一步地，在针对业务创建有缓存池情况下，本申请针对如何回收使用后的共享内存，还对应的提供了较为优选的共享内存回收方式。具体方式如下：

在所述节点中的目的节点完成数据使用时，使用回调通知控制管道共享内存使用完毕，通过控制管道调用缓存池进行共享内存回收。

进一步地，该方式可以包括：

判断所述缓存池中当前空闲的共享内存数量是否小于预设阈值；

如果是，则将所述待处理数据所使用的共享内存清理后重新存储；

如果否，则将所述待处理数据所使用的共享内存释放掉。

这种方式可以根据业务的实际需求情况，灵活地管理缓存池中的共享内存，以达到在满足业务需求的情况下，尽可能少占用系统内存资源。

当然，在实际应用中，也可以直接将共享内存清理后重新存储，还可以直接释放共享内存，但显然上述方式的效果更好。

在现有技术中，各个进程之间通过调用的方式实现针对某个业务的数据处理。因此，当业务需求发生变化时，开发人员就需要对实现该业务的相关进程以及调用关系进行适应性修改；而在实际应用中，业务需求的更新频率非常高，这就需要频繁的修改进程以及调用关系，系统适用性较低，且代码调整的工作量繁琐且巨大，很难保证业务调用响应的及时性。

为了解决上述问题，本申请还提供了对应的解决方法，该方法具体可以在上述图1所示方法的基础上，增加如下步骤：

接收所述控制管道的节点挂载信息，根据接收到的节点挂载信息更新所述控制管道上挂载的节点。

对于研发人员来说，不需要修改进程的源代码，只需要根据业务的实际需求，修改控制管道的节点挂载信息即可，其工作量大大减小。

在实现时，更新控制管道上挂载的节点，主要是利用节点实例化地址对实现业务的节点信息进行设置，其中，节点信息包括：节点序号、节点等待信号、节点通知信号等。

接下来，对更新控制管道上挂载的节点的具体情况进行解释说明。

在执行更新操作时，首先，通知控制管道上的所有节点停止数据处理并退出所有处理线程；然后，调整节点链表；最后，通知所有节点重新启动数据处理线程。

其中，节点列表的调整方式有以下几种：

(1)更换源节点：复制原源节点的通知信号和节点序号，将节点链表中首个节点删除插入新源节点。更换源节点必须确保新的源节点的通知信号和节点序号与原来的源节点的相同，因此，通过复制的方式保证新的源节点和原源节点的这些信息保持一致。

(2)移除中间节点：利用节点序号在链表中查找待移除节点，设置当前节点的前一个节点的通知信号作为下一个节点的等待信号，依次调整后续节点序号，最后在链表中移除该节点。

(3)插入新中间节点：利用节点序号在链表中查找插入位置，设置当前节点的前一个节点的通知信号作为该节点的等待信号，设置当前节点的通知信号为下一个节点的等待信号，依次调整后续节点序号。

(4)更换目的节点：复制原目的节点的等待信号和节点序号，将节点链表中最后一个节点删除插入新目的节点。

在一次更新操作时，可能执行以上四种调整方式中的任意一种或者任意多种，具体采用哪种根据实际情况而定，本申请对此不作具体限定。

另外，本申请发明人还考虑到，在对业务的数据进行处理时，可能会出现在某一个环节数据处理异常或者出错，但系统还会触发下一个环节的处理，直到完成整个处理流程，这样，既不能够及时发现数据异常的问题，又会浪费系统资源。

为了解决上述问题，本申请还提供了对应的解决方法，该方法具体是在上述图1所示方法的基础上，还增加如下步骤：

所述节点判断数据的有效性，如果数据无效，则所述节点通知所述控制管道回收数据，并控制所述节点中的目的节点将错误结果通知给应用层。

在实际应用中，根据业务的实际需求来设置数据有效性的标准，所有节点可以基于该标准来判断数据的有效性。比如，数据长度大小标准、数据关键字段信息标准等等。本申请对具体的标准内容不作任何限定。

通过这种方式，可以及时地发现数据是否异常，进而能够在第一时间通知应用层数据处理异常，另外，还能够尽早回收数据，以提高数据在控制管道中的流转效率，尽可能地少占用系统资源。

以上对本申请提供的一种共享内存管理方法进行了解释说明。

下面对本申请提供的一种共享内存管理装置进行解释说明。

参见图4，图4是本申请提供的一种共享内存管理装置的结构图，该装置包括：控制管道创建及节点挂载模块401和数据处理模块402；下面基于该装置的工作原理对各单元的功能以及连接关系进行解释说明。

控制管道创建及节点挂载模块401，用于针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；

数据处理模块402，用于当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

可选的，所述数据处理模块，可以包括：

共享内存传递处理子模块，用于当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间按照内核事件通知机制传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。

可选的，所述共享内存传递处理子模块，可以包括：

共享内存申请子模块，用于通过所述控制管道控制所述节点中的源节点向系统申请共享内存；

节点数据处理子模块，用于通过所述控制管道控制所述节点中的源节点对申请到的共享内存进行数据初始化，并控制所述节点中的源节点和中间节点都通过内核事件信号通知机制向所述节点中的下一个节点传递所述共享内存和处理后的数据，以完成对所述待处理数据的处理。

可选的，所述装置还可以包括：

缓存池创建模块，用于针对所述业务创建缓存池，根据所述业务的需求向系统申请多个共享内存，在所述缓存池中存储所述多个共享内存的地址；则所述待处理数据所使用的共享内存是由所述节点中的源节点从所述缓存池中申请的一个共享内存。

可选的，所述缓存池创建模块，可以包括：

存储子模块，用于在所述缓存池中使用链表存储所述多个共享内存的地址。

可选的，所述装置还可以包括：共享内存回收模块，用于当所述待处理数据处理完毕时，回收使用后的共享内存。

进一步地，所述共享内存回收模块，可以包括：

判断子模块，用于判断缓存池中当前空闲的共享内存数量是否小于预设阈值；如果是，进入重新存储子模块；如果否，释放子模块；

重新存储子模块，用于将所述待处理数据所使用的共享内存清理后重新存储；

释放子模块，用于将所述待处理数据所使用的共享内存释放掉。

可选的，所述装置还可以包括：

有效性判断模块，用于控制所述节点判断数据的有效性，如果数据无效，则所述节点通知所述控制管道回收数据，并控制所述节点中的目的节点将错误结果通知给应用层。

可选的，所述控制管道创建及节点挂载模块，可以包括：

节点挂载子模块，用于根据所述业务的数据处理顺序，将实现所述业务的所述节点中的源节点、中间节点和目的节点的实例化地址依次存储至所述控制管道维护的节点链表中，并使用回调机制与所述控制管道建立通知关系。

可选的，所述装置还可以包括：

节点调整模块，用于接收所述控制管道的节点挂载信息，根据接收到的节点挂载信息更新所述控制管道上挂载的节点。

本申请提供的上述装置，考虑到多进程软件系统中业务处理是依赖于进程间的相互关联的数据处理来实现的，提出了针对一种业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道的方式，其中，节点包括不同进程实现的功能节点，这种将进程功能节点化的方式，可以使不同的业务共用同一进程的不同功能节点，能够更加灵活地使用已有进程；再者这种节点挂接方式，方便根据业务需求动态调整数据处理流程，能够提高系统适用性。

当该业务有数据需要处理时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内容，以实现对所述待处理数据的处理；当所述待处理数据处理完毕时，回收使用后的共享内存。该方法不需要依赖进程间的直接地调用，而是通过业务的控制管道控制节点实现对数据的处理，从而能够降低进程间的耦合性。

此外，本申请提供的装置还可以针对所述业务创建缓存池，根据所述业务的需求向系统申请多个共享内存，在所述缓存池中存储所述多个共享内存的地址；这样，通过共享内存的缓存功能，可以支持多组数据的处理，减少频繁动态申请和释放内存造成的系统内存激增现象。

进一步地，本申请还提供了一种共享内存管理系统，该系统可以包括：至少一个处理器(例如CPU)和至少一个存储器。

其中，处理器用于执行存储器中存储的可执行指令，例如计算机程序。

存储器可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个网络接口(可以是有线或者无线)实现该系统网关与至少一个其他网元之间的通信连接。

当然，所述系统还可以包括至少一个网络接口或者其他通信接口和至少一个通信总线，用于实现系统内各个部件之间的连接通信。

参见图5，在一些实施方式中，存储器中存储了可操作指令，程序指令可以被处理器执行。其中，可操作指令包括：

针对业务创建共享内存的控制管道，将实现所述业务的节点挂接在所述控制管道，所述节点包括：由不同的进程实现的功能节点，一个进程包括一个或多个功能节点；

当接收到所述业务的待处理数据时，通过所述控制管道控制所述节点之间传递处理所述待处理数据所使用的共享内存，以实现对所述待处理数据的处理。当然，存储器中存储的可操作指令也还可以包括上述方法实施例中描述的算法步骤。

如图5所示，共享内存管理系统500包括：处理器501和存储器502，存储器502中存储有上述可操作指令，处理器501从存储器502中读取并执行这些指令，以实现相应功能。专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。