CN117009109A - 进程间数据共享方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供一种进程间数据共享方法、装置及电子设备，所述方法包括接收第一进程发送的共享区域申请请求，其中，共享区域申请请求用于申请用户态共享地址空间内的区域，基于共享区域申请请求为第一进程分配与待占用区域的内存大小对应的目标区域，并为目标区域分配虚拟地址和物理地址，接收第二进程发送的关联请求，并根据关联请求将第二进程与第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致，根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。提高了数据交互的效率。

Description

进程间数据共享方法、装置及电子设备

技术领域

本申请实施例涉及汽车控制技术领域，尤其涉及一种进程间数据共享方法、装置及电子设备。

背景技术

随着网络技术的发展，内核操作系统的应用越来越广泛，微内核由于安全性高的优点也越来越受到重视。

现有技术中，在微内核操作系统中，微内核操作系统的内存地址空间一般分为内核态地址空间和用户态地址空间。内核态地址空间可以被所有进程共享，用户态地址空间保持进程独立，不被共享，运行在用户态地址空间的代码，无权直接访问内核态地址空间的数据，以及其它进程的用户态地址空间的数据。

然而，与车辆相关的大多数系统服务均需要从内核态地址空间剥离到用户态地址空间内执行，而在用户态地址空间内，各进程之间由于没有权限直接进行访问，往往需要繁琐的操作过程才可以实现数据交互，降低了数据交互的效率，进而影响了业务的实现效果。

发明内容

本申请实施例提供一种进程间数据共享方法、装置及电子设备，以提高数据交互的效率。

第一方面，本申请实施例提供一种进程间数据共享方法，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，所述方法包括：

接收第一进程发送的共享区域申请请求，其中，所述共享区域申请请求用于申请所述用户态共享地址空间内的区域，所述共享区域申请请求中包含待占用区域的内存大小；

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，并为所述目标区域分配虚拟地址和物理地址；

接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致；

根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

可选的，所述基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，包括：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域；

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

可选的，所述为所述目标区域分配虚拟地址和物理地址，包括：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程；

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

可选的，所述根据所述映射请求为所述区域编号对应的目标区域分配物理地址，包括：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

可选的，所述接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，包括：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号；

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

可选的，在进程申请或关联所述目标区域之后，所述目标区域的引用个数会对应增加一个，在所述根据区域关联后的第一进程以及第二进程实现数据的共享操作之后，还包括：

接收所述第一进程和/或所述第二进程发送的解除请求；

根据所述解除请求对所述第一进程和/或所述第二进程，与所述目标区域进行关联解除处理；

将所述引用个数减一，得到新的引用个数。

可选的，在所述将所述引用个数减一，得到新的引用个数之后，还包括：

若所述新的引用个数为零，则释放所述目标区域。

第二方面，本申请实施例提供一种进程间数据共享装置，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，所述装置包括：

接收模块，用于接收第一进程发送的共享区域申请请求，其中，所述共享区域申请请求用于申请所述用户态共享地址空间内的区域，所述共享区域申请请求中包含待占用区域的内存大小；

处理模块，用于基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，并为所述目标区域分配虚拟地址和物理地址；

所述处理模块，还用于接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，其中，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致；

所述处理模块，还用于根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

第三方面，本申请实施例提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，实现如上第一方面以及第一方面各种可能的设计所述的进程间数据共享方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计所述的进程间数据共享方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的进程间数据共享方法。

本申请实施例提供一种进程间数据共享方法、装置及电子设备，采用上述方案后，可以先接收第一进程发送的共享区域请求，用于申请用户态共享地址空间内的区域，且共享区域申请请求中包含待占用区域的内存大小，然后可以基于共享区域申请请求为第一进程分配与待占用区域的内存大小对应的目标区域，并为目标区域分配虚拟地址和物理地址，然后可以接收第二进程发送的关联请求，并根据关联请求将第二进程与第一进程对应的目标区域进行关联处理，使得关联处理后第二进程的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致，然后可以根据关联后的第一进程以及第二进程实现目标业务数据的共享操作，进而实现目标业务，通过将业务相关联的第一进程与第二进程授权关联到用户态共享地址空间内的目标区域，可以实现第一进程与第二进程均具有访问目标区域的权限，进而实现进程间数据的共享，简化了数据交互的过程，提高了数据交互的效率，进而提高了业务的实现效果。

附图说明

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

图1为现有技术中实现进程间数据共享的原理示意图；

图2为本申请实施例提供的进程间数据共享方法的流程示意图；

图3为本申请实施例提供的内存地址的空间示意图；

图4为本申请实施例提供的进程间数据共享的时序流程图；

图5为本申请实施例提供的目标区域关联的原理示意图；

图6为现有技术中宏内核结构中复杂数据结构交互的应用示意图；

图7为现有技术中微内核结构中复杂数据结构交互的应用示意图；

图8为现有技术中复杂数据结构的交互流程图；

图9为现有技术中另一复杂数据结构的交互流程图；

图10为本申请另一实施例提供的进程间数据共享方法的流程示意图；

图11为本申请实施例提供的复杂数据共享过程的原理示意图；

图12为本申请实施例提供的多进程间复杂数据的内存分布示意图；

图13为本申请实施例提供的复杂数据访问过程的原理示意图；

图14为现有技术中远程过程调用的原理示意图；

图15为本申请另一实施例提供的进程间数据共享方法的流程示意图

图16为本申请实施例提供的服务进程应用的原理示意图；

图17为本申请实施例提供的多个目标区域的应用示意图；

图18为本申请实施例提供的共享资源同步的应用示意图；

图19为本申请实施例提供的共享资源同步的时序流程图；

图20为本申请实施例提供的进程间数据共享装置的结构示意图；

图21为本申请实施例提供的电子设备的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例还能够包括除了图示或描述的那些实例以外的其他顺序实例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前主要有宏内核和微内核两种架构的操作系统，在两种架构下，系统服务是不同的设计思想。宏内核是一种一体化内核结构，通常将进程管理、内存管理、网络、设备驱动，文件系统等各项功能都放到内核中去实现，常见的宏内核有Unix、Linux等。拿Linux来看，用户态应用程序需要系统服务时，会通过系统调用进入到内核态，因为系统服务逻辑运行在统一的地址空间，相关的系统服务逻辑之间可以直接进行访问(数据和代码)，数据交互仅发生在系统调度，传入内核和传出内核。微内核是一种化整为零的内核结构，内核仅提供任务调度、内存管理、异常处理等OS基本能力，而将系统服务(网络、文件系统、驱动等)拆分成一个个独立的组件，这些组件运行在用户态，常见的微内核OS有QNX、Minix等。这种架构的内核，用户态应用程序通常通过IPC(Inter Process Communication，进程间通信)的方式通知系统服务进程，相关的系统服务进程之间也可以通过IPC来共同完成应用程序所要求的一项功能。例如，APP要求显示实时处理摄像，该项功能可能涉及到Camera、GPU，Display等相关驱动服务进程，Camera驱动负责图像采集，GPU驱动负责图像处理，显示驱动负责图像输出展示，这些驱动通常以独立的进程运行在用户态，地址空间独立，因此数据需要在不同进程间进行传递共享，效率远远低于宏内核。在微内核操作系统中，微内核操作系统的内存地址空间一般分为内核态地址空间和用户态地址空间。内核态地址空间可以被所有进程共享，用户态地址空间保持进程独立，不被共享，运行在用户态地址空间的代码，无权直接访问内核态地址空间的数据，以及其它进程的用户态地址空间的数据。然而，与车辆相关的大多数系统服务均需要从内核态地址空间剥离到用户态地址空间内执行，而业务之间由于没有权限直接进行访问，往往需要繁琐的操作过程才可以实现数据交互，降低了数据交互的效率，进而影响了业务的实现效果。即大多数的系统服务，从内核态地址空间剥离到用户态地址空间内执行。而系统服务之间，往往有较为苛刻的数据交互需求，如数据结构复杂，数据量大，效率要求高等。但操作系统的常规设计，运行在用户态的(系统服务)代码，无权直接访问内核态地址空间内的数据，也无权访问其它进程(其它系统服务)的用户态地址空间的数据。因此在微内核操作系统中的系统服务如何高效、安全地共享数据，为本发明主要解决的技术问题。

微内核操作系统的系统服务间在通过IPC来满足跨进程的数据交换时，主要有两类方式：图1为现有技术中实现进程间数据共享的原理示意图，如图1所示，在一种实现过程中，可以通过消息传递(例如，pipe/message或者queue/mailbox等)把一个驱动服务进程的数据中拷贝到另一个驱动服务进程中。此外，在另一种实现方式中，可以借助共享内存，两个进程事先都从共享内存服务申请一块buffer，映射到各自进程的地址空间内。

然而，以上两种常见方式都有两个比较严重的缺点，如果传递的数据中含有地址信息，则需要接收方地址信息所描述的空间映射到本进程才可以访问，或者通过序列化方式传实际内容，在多级地址情况下会变得非常复杂，并且在出错时对问题定位会造成干扰。另外，如果数量较大，将极大影响系统服务的整体处理效率。

基于上述技术问题，本申请通过将业务相关联的第一进程与第二进程授权关联到用户态共享地址空间内的目标区域，可以实现第一进程与第二进程均具有访问目标区域的权限，且第一进程和第二进程对同一块物理地址的虚拟地址是一样的，两个进程可以直接访问一样的虚拟地址，不需要额外进行地址转换，进而实现了进程间数据的共享，简化了数据交互的过程，提高了数据交互的效率，且在保证数据隔离性与安全性的情况下，达到了提高业务的实现效果的技术效果。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本申请实施例提供的进程间数据共享方法的流程示意图，本实施例的方法可以由微内核操作系统执行，可以为部署于汽车中的微内核操作系统，具体可以由微内核操作系统中的内存管理单元(或者称为x space管理单元)来执行。如图2所示，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，本实施例的方法，可以包括：

S201：接收第一进程发送的共享区域申请请求，其中，共享区域申请请求用于申请用户态共享地址空间内的区域，共享区域申请请求中包含待占用区域的内存大小。

在本实施例中，常规操作系统的内存地址空间可以分成内核态地址空间(kernelspace)和用户态地址空间(user space)两部分。内核态地址空间被所有进程共享，用户态地址空间保持进程独立，不被共享，即运行在用户态地址空间的代码，无权直接访问内核态地址空间的数据，以及其它进程的用户态地址空间的数据。

图3为本申请实施例提供的内存地址的空间示意图，如图3所示，为了解决上述问题，可以在用户态地址空间中预留出一片区域，称为用户态共享地址空间，也可以称为进程虚实一致地址空间(x space)，用户态共享地址空间可以与常规的user space以及kernelspace相互不重叠，且在64位的处理器体系架构里，用户态共享地址空间的大小可以被配置的非常大。此外，user space可以分配在低地址空间，kernel space可以分配在高地址空间。

此外，在设置完成用户态共享地址空间之后，用于实现汽车上的目标业务的第一进程需要与其他实现该目标业务的第二进程共享数据，因此，可以接收第一进程发送的共享区域申请请求。

S202：基于共享区域申请请求为第一进程分配与待占用区域的内存大小对应的目标区域，并为目标区域分配虚拟地址和物理地址。

在本实施例中，在接收到第一进程发送的共享区域申请请求之后，可以根据共享区域申请请求中包含的待占用区域的内存大小，为第一进程分配与待占用区域的内存大小对应的目标区域(即region区域)，即x space管理单元可以在x space空间创建一个页对齐的region区域，并返回区域编号(也可称为region id)和目标区域对应的虚拟地址。另外，初始化目标区域的引用计数可以为1。

进一步的，所述基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，可以包括：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域。

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

具体的，操作系统无需为各进程预先分配目标区域，各进程也没有用户态共享地址空间地址的访问权限，保持与传统操作系统的向前兼容。各进程在运行态时，可向xspace管理单元一次或多次申请目标区域，目标区域的地址空间大小可以不固定，并通过参数传递给x space管理单元。即在根据共享区域申请请求为第一进程分配目标区域时，目标区域的起始虚拟地址可以有多种分配方式。可选的，可以随机确定起始虚拟地址，还可以指定起始虚拟地址。对应的，共享区域申请请求中的参数方式可以为待占用区域的内存大小，指定起始虚拟地址；或者，待占用区域的内存大小，不指定起始虚拟地址，提高了虚拟地址分配的灵活性。

此外，还可以为目标区域分配物理地址。

进一步的，所述为所述目标区域分配虚拟地址和物理地址，可以包括：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程。

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

具体的，在为第一进程的目标区域分配了区域编号和虚拟地址之后，可以继续为区域编号对应的该目标区域分配物理地址。此外，x space管理单元可以支持在目标区域内，以更小粒度地进行“虚拟地址”和“物理地址”的映射关系的建立及解除。示例性的，可以以pages粒度(4KB的整数倍，最小为4KB)地将物理空间和目标区域内的虚拟空间建立映射关系。

更进一步的，所述根据所述映射请求为所述区域编号对应的目标区域分配物理地址，可以包括：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

具体的，在为目标区域分配物理地址时，可以有多种分配方式。可选的，可以根据映射请求为区域编号对应的目标区域分配连续的物理地址，或者分配非连续的物理地址。可选的，物理地址的起始地址可以为随机分配的或指定的。可选的，还可以指定具体设备的物理空间(即物理地址)与虚拟空间建立映射关系。

综上，增加了虚拟地址和物理地址选择方式的灵活性。

S203：接收第二进程发送的关联请求，并根据关联请求将第二进程与第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致。

在本实施例中，用于与第一进程实现相同业务的一个或多个第二进程可以向内存管理单元发送关联请求，用于关联第一进程申请的目标区域。然后可以根据第二进程发送的关联请求，将第二进程与第一进程对应的目标区域进行关联处理，以使关联处理后的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致。

进一步的，所述接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，可以包括：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号。

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

具体的，第二进程发送的关联请求中可以包含区域编号，该区域编号为第一进程申请的目标区域对应的编号，然后可以根据关联请求将第二进程对应的关联区域与区域编号对应的目标区域进行关联处理。

此外，第二进程可以通过IPC的方式来获得第一进程的区域编号，在此不再详细进行论述。

图4为本申请实施例提供的进程间数据共享的时序流程图，如图4所示，在该实施例中，第一进程申请到的目标区域，可以被x space管理单元关联到其它第二进程的地址空间里，这个目标区域在关联进程中的虚拟地址相等，因此目标区域里的虚拟地址，可以被所有关联进程访问。例如，第一进程为进程A，第二进程为进程B和进程C，内存管理单元可以允许或支持进程以更细粒度(如page粒度)从x sapce空间中“申请”、“释放”目标区域，称为region。例如，进程A从x space空间申请R1，进程B将R1映射到本进程，此外，进程B也可以作为第一进程，进程A作为第二进程，即进程B申请R3、R5对应的目标区域，支持进程A和进程C将R3映射到本进程，同时也支持解除目标区域(即region)在进程中映射的解除。

S204：根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

在本实施例中，在为第一进程和第二进程关联相同的目标区域之后，第一进程和第二进程均有访问和修改目标区域的权限，然后可以根据第一进程以及第二进程来对目标区域处理的数据进行处理，进而实现目标业务。示例性的，可以实现车辆导航业务或者车辆指示灯检测业务等。

此外，只有授信进程才能向x space管理单元申请和释放目标区域，避免恶意进程访问到其它进程的在目标区域内的数据，包含了数据的安全性。

采用上述方案后，可以先接收第一进程发送的共享区域请求，用于申请用户态共享地址空间内的区域，且共享区域申请请求中包含待占用区域的内存大小，然后可以基于共享区域申请请求为第一进程分配与待占用区域的内存大小对应的目标区域，并为目标区域分配虚拟地址和物理地址，然后可以接收第二进程发送的关联请求，并根据关联请求将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，使得关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致，然后可以根据关联后的第一进程以及第二进程实现目标业务数据的共享操作，进而实现目标业务，通过将业务相关联的第一进程与第二进程授权关联到用户态共享地址空间内的目标区域，可以实现第一进程与第二进程均具有访问目标区域的权限，进而实现进程间数据的共享，简化了数据交互的过程，提高了数据交互的效率，进而提高了业务的实现效果。

基于图2的方法，本说明书实施例还提供了该方法的一些具体实施方案，下面进行说明。

在另一实施例中，在进程申请或关联所述目标区域之后，所述目标区域的引用个数会对应增加一个，在所述根据区域关联后的第一进程以及第二进程实现数据的共享操作之后，还可以包括：

接收所述第一进程和/或所述第二进程发送的解除请求。

根据所述解除请求对所述第一进程和/或所述第二进程，与所述目标区域进行关联解除处理。

将所述引用个数减一，得到新的引用个数。

在本实施例中，为了提高目标区域管理的便利性，可以根据目标区域的申请以及关联数量来更新目标区域的引用个数。即第一进程在向x space管理单元申请目标区域之后，目标区域的引用个数可以设置为1，第二进程在关联目标区域之后，可以根据关联目标区域的第二进程的数量来更新引用个数、示例性的，若只有一个第二进程来关联目标区域，则引用个数更新为2。若有五个第二进程来关联目标区域，则引用个数更新为6。

此外，第一进程或第二进程还可以发送解除请求，然后可以根据该解除请求解除目标区域与第一进程或第二进程的映射关系，并在解除映射关系之后更新引用个数。可选的，解除第一进程与第二进程的映射关系可以不限定顺序，且每解除一个进程的映射关系，则将引用个数减一，得到新的引用个数。

此外，在所述将所述引用个数减一，得到新的引用个数之后，还可以包括：

若所述新的引用个数为零，则释放所述目标区域。

具体的，在得到新的引用个数之后，可以先判断引用个数是否为零，若为零，则表示没有进程引用该目标区域，则可以释放该目标区域，即收回该目标区域，具体收回方式可以采用现有方式，在此不再详细进行限定。

图5为本申请实施例提供的目标区域关联的原理示意图，如图5所示，在该实施例中，主要涉及到第一进程、第二进程以及x space管理单元之间的交互过程，第一进程需要共享与汽车相关的目标业务的数据，可以先向x space管理单元申请一块大小为size的目标区域，x space管理单元可以在用户态共享地址空间创建一个页对齐的目标区域，并返回区域编号和目标区域对应的虚拟地址，初始化目标区域的引用计数为1。第一进程还可以申请该目标区域的物理地址映射，x space管理单元负责将目标区域区域内一段大小为size1(size1小于或等于size)的空间与大小为size1的物理地址进行映射并返回物理地址。第二进程若需要跟第一进程数据共享，则需要关联目标区域。首先第二进程可以通过IPC获得第一进程的目标区域的区域编号，然后向x space管理单元申请关联该目标区域，x space管理单元完成第二进程跟目标区域的关联和映射，同时目标区域的引用计数加一，x space管理单元会在第二个进程关联目标区域时，将目标区域中size1大小的物理地址和虚拟地址映射成跟第一个进程一致。

可选的，还可以在第一进程申请目标区域返回虚拟地址后，第二进程关联目标区域，此时第一、二进程的虚拟地址一致；然后第一进程再将该虚拟地址映射到size1大小的物理区域，那么第一进程和第二进程的虚拟地址都会映射到相同的物理地址。第一进程目标区域物理地址的映射和其它第二进程的关联操作，可以不分先后。

前边步骤完成后，第一进程和第二进程关联的目标区域实现了虚实地址一致。第一进程和第二进程对目标区域的虚拟内存可以直接访问，可完成后续一系列数据的交互操作。此外，第二进程完成共享数据交互后，可以向x space管理单元申请解除目标区域关联，x space管理单元完成关联解除和地址解映射，目标区域的引用计数减一。若第一进程不需要共享数据时，可以申请解除地址映射，目标区域的引用计数也减一。第一进程向x space管理单元申请释放目标区域。可选的，目标区域关联解除和解映射，第一进程和第二进程的先后顺序不固定，x space管理单元会根据目标区域引用计数决定是否真正回收。

综上，可以实现一种内核内存管理单元虚实一致的内存管理方法，以及目标区域的管理方法和使用规则，有利于进程间数据共享效率的提升。此外，在微内核架构操作系统的用户态空间上，模拟出了一个类似Linux宏内核的内核空间，用户态进程间可以使用虚实一致共享；各个进程可申请独立拥有这个区间里的不同目标区域，根据需要，业务相关联的进程可以授权关联到指定的目标区域以达到进程间直接共享数据的效果。不需要像现有方案中微内核系统进程间数据通信那样，需要多次拷贝或者地址转换等影响数据交互的效率的操作。该方法既具有宏内核的高效、简单的优点，满足进程间共享数据的效率，又具有微内核操作系统进程隔离的特点，满足安全性，达到了高效、安全、灵活的目的。

此外，与车辆相关的大多数系统服务均需要从内核态地址空间剥离到用户态地址空间内执行，而各进程之间由于没有权限直接进行访问，往往需要繁琐的操作过程才可以实现数据交互，尤其是对于复杂数据，降低了复杂数据交互的效率，进而影响了服务的实现效果。

宏内核是一种传统的内核结构，它将进程管理、内存管理、网络、设备驱动，文件系统等各项服务功能都放到内核中去，常见的宏内核有Unix，Linux等。这种架构的内核，用户态应用程序需要系统服务时，会通过系统调用进入到统一地址空间的内核态中。因为系统服务统一运行在内核态地址空间，不同系统服务之间没有地址隔离，数据交互可以直接进行。耗时的数据交互仅发生在进程的内核态和用户态之间。即使再复杂的数据结构，各个系统服务(包括驱动)均可直接访问。图6为现有技术中宏内核结构中复杂数据结构交互的应用示意图，如图6所示，应用程序通过系统调用后可以访问到内核空间的驱动程序，指针ptr指向的数据是驱动程序1，2，n都需要使用的。内核态的地址空间对驱动程序1，2，n来说都是可见的且可以直接访问的，各驱动程序获取到ptr指针后就能直接访问到复杂数据结构内部的各级指针对应的数据。

而微内核是内核的一种精简形式，将通常与内核集成在一起的系统服务、驱动等分离出来，变成可以根据需求加入的选件，这样就可提供更好的可扩展性和更加安全的应用环境，常见的微内核有QNX、SEL4等。但系统服务之间，往往需要数据交互。以多媒体运用为例，系统中可能存在camera、GPU、display等不同的驱动服务进程，camera驱动负责图像采集，GPU驱动负责图像处理，显示驱动负责图像输出和展示。但这些驱动服务的代码，运行在不同的用户态地址空间，且地址相互隔离。图7为现有技术中微内核结构中复杂数据结构交互的应用示意图，如图7所示，驱动程序1中vaddr1及其内部指针指向的vaddr2以及vaddr3，驱动程序2是不能直接获取和访问的，因此数据需要在不同进程间进行传递、共享，不像宏内核架构那么便利高效。

此外，对于复杂数据结构，现有的微内核操作系统的系统服务间的数据交互，可以有多种方式：

可选的，可以通过IPC(Inter Process Communication，进程间通信)的方式来进行复杂数据结构的交互，内核会将一个驱动服务进程的数据拷贝到另一个驱动服务进程中，图8为现有技术中复杂数据结构的交互流程图，如图8所示，一个进程的指针(即地址)，另一个进程是无法直接使用的，因此对于存在多级指针的情况下，则需要遍历各级指针，把所有指针指向的数据都拷贝到另一个进程中。如驱动程序1需要将vaddr1的内容通过IPC通信拷贝到驱动程序2的vaddr1'内存空间中，此时vaddr1'中vaddr2以及vaddr3的指针驱动程序仍然不能直接访问，需要将驱动程序1中vaddr2和vaddr3的内容也依次拷贝到驱动程序2的vaddr2'和vaddr3'的内存空间中，同时驱动程序2的vaddr1'的内部指针vaddr2和vaddr3替换成vaddr2'和vaddr3'，操作过程复杂，增大了代码实现的难度，降低了数据传递的效率。

可选的，还可以借助共享内存的方法，两个进程事先都将共享内存服务申请的一块buffer映射到自身进程的地址空间内。一个进程A把数据写到这个buffer后通过IPC消息或者其它方式通知到另一进程B，进程B就可以直接访问映射好的共享内存中的数据，达到数据共享的目的。由于同一个buffer空间，映射在不同进程的地址可能是不相同的，对于多级指针的情况，假设buffer中共享数据中存在二级指针，这个地址是进程A有效的，进程B还是不能直接访问，需要进行地址转换。图9为现有技术中另一复杂数据结构的交互流程图，如图9所示，驱动程序1将一段共享内存map到本进程，将需要共享的vaddr1内容写入到map后的地址vaddr1'中，将vaddr2和vaadr3的内容也依次写入共享内存中，根据offset可以得到本进程的map地址vaddr2'和vaddr3'，然后通过IPC将共享内存信息传递给驱动程序2，驱动程序2根据共享内存信息进行地址映射，并根据offset进行地址转换后，会得到本进程空间对应的共享数据内容的指针vaddr1”、vaddr2”和vaddr3”，处理过程繁琐。

可选的，还可以通过IPC的方式，进程A将第一级指针传递给另一进程B，在进程B中依次将各级指针map到进程B，进程B可以直接访问map后的地址，但map的效率并不高，对于性能要求高的场景不适用。

综上，虽然以上方案都能实现服务间数据交互，但都没有宏内核在内核态直接共享数据那般直接、快速，如果指针层级更多一些，可能会需要更多次的地址转换操作，影响了数据的传递效率，进而影响了服务的实现效果。

基于上述问题，图10为本申请另一实施例提供的进程间数据共享方法的流程示意图，在该实施例中，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，如图10所示，所述方法包括：

S1001：将第二进程与第一进程对应的目标区域进行关联处理，其中，目标区域为用户态共享地址空间内的区域，关联处理后的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致。

在本实施例中，进程间交互的数据可能为复杂数据，示例性的，可以为多级指针嵌套结构的数据，在交互的数据为复杂数据时，可以以用户态共享地址空间中的目标区域为基础来实现复杂数据的交互，进而提高复杂数据交互的效率。

进一步的，所述将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，具体可以包括：

接收第一进程发送的共享区域申请请求，并根据所述共享区域申请请求为所述第一进程分配与待占用区域的内存大小对应的目标区域。

为所述目标区域分配虚拟地址和物理地址。

接收第二进程发送的关联请求，并根据所述关联请求将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，其中，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

具体的，在接收到第一进程发送的共享区域申请请求之后，可以根据共享区域申请请求中包含的待占用区域的内存大小，为第一进程分配与待占用区域的内存大小对应的目标区域(即region区域)，即x space管理单元可以在x space空间创建一个页对齐的region区域，并返回区域编号(也可称为region id)和目标区域对应的虚拟地址。另外，初始化目标区域的引用计数可以为1。

进一步的，所述基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，可以包括：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域。

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

具体的，操作系统无需为各进程预先分配目标区域，各进程也没有用户态共享地址空间地址的访问权限，保持与传统操作系统的向前兼容。各进程在运行态时，可向xspace管理单元一次或多次申请目标区域，目标区域的地址空间大小可以不固定，并通过参数传递给x space管理单元。即在根据共享区域申请请求为第一进程分配目标区域时，目标区域的起始虚拟地址可以有多种分配方式。可选的，可以随机确定起始虚拟地址，还可以指定起始虚拟地址。对应的，共享区域申请请求中的参数方式可以为待占用区域的内存大小，指定起始虚拟地址；或者，待占用区域的内存大小，不指定起始虚拟地址，提高了虚拟地址分配的灵活性。

此外，还可以为目标区域分配物理地址。

进一步的，所述为所述目标区域分配虚拟地址和物理地址，可以包括：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程。

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

具体的，在为第一进程的目标区域分配了区域编号和虚拟地址之后，可以继续为区域编号对应的该目标区域分配物理地址。此外，x space管理单元可以支持在目标区域内，以更小粒度地进行“虚拟地址”和“物理地址”的映射关系的建立及解除。示例性的，可以以pages粒度(4KB的整数倍，最小为4KB)地将物理空间和目标区域内的虚拟空间建立映射关系。

更进一步的，所述根据所述映射请求为所述区域编号对应的目标区域分配物理地址，可以包括：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

具体的，在为目标区域分配物理地址时，可以有多种分配方式。可选的，可以根据映射请求为区域编号对应的目标区域分配连续的物理地址，或者分配非连续的物理地址。可选的，物理地址的起始地址可以为随机分配的或指定的。可选的，还可以指定具体设备的物理空间(即物理地址)与虚拟空间建立映射关系。

综上，增加了虚拟地址和物理地址选择方式的灵活性。

此外，用于与第一进程实现相同业务的一个或多个第二进程可以向内存管理单元发送关联请求，用于关联第一进程申请的目标区域。然后可以根据第二进程发送的关联请求，将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，以使关联处理后的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致。

进一步的，所述接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，可以包括：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号。

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

具体的，第二进程发送的关联请求中可以包含区域编号，该区域编号为第一进程申请的目标区域对应的编号，然后可以根据关联请求将第二进程对应的关联区域与区域编号对应的目标区域进行关联处理。

此外，第二进程可以通过IPC的方式来获得第一进程的区域编号，在此不再详细进行论述。

S1002：接收第一进程发送的复杂数据内存申请请求，其中，复杂数据内存申请请求中包含复杂数据的数据结构。

在本实施例中，在为第一进程分配目标区域之后，还可以接收第一进程发送的复杂数据内存申请请求。其中，该复杂数据内存申请请求中包含复杂数据的数据结构，即复杂数据的具体结构。示例性的，复杂数据为三级指针，则复杂数据内存申请请求中包含三级指针的数据结构。

S1003：基于复杂数据内存申请请求从目标区域中确定与复杂数据的数据结构对应的子区域。

在本实施例中，在接收到复杂数据内存申请请求之后，可以基于该复杂数据内存申请请求从目标区域中来确定与复杂数据的数据结构对应的子区域。

进一步的，所述复杂数据的数据结构为多层指针嵌套结构，所述基于所述复杂数据内存申请请求从所述目标区域中确定与所述复杂数据的数据结构对应的子区域，可以包括：

基于所述复杂数据内存申请请求从所述目标区域中确定与所述复杂数据中的第N层指针对应的第一子区域，并保存所述第一子区域的第一首地址，其中，N为自然数，且小于或等于所述多层指针嵌套结构的指针层数。

基于所述复杂数据内存申请请求从所述目标区域中确定与第N+1层指针对应的第二子区域，并将所述第二子区域的第二首地址存储至所述第一首地址对应的第一子区域中，其中，所述第一子区域与所述第二子区域均属于所述子区域。

具体的，若复杂数据的数据结构为多层指针嵌套结构，则可以基于复杂数据内存申请请求先从目标区域中确定与复杂数据中的第N层指针对应的第一子区域，并保存第一子区域的第一首地址。然后可以基于复杂数据内存申请请求从目标区域中确定与第N+1层指针对应的第二子区域，并将第二子区域的第二首地址存储至第一首地址对应的第一子区域中。

此外，第一子区域和第二子区域可以组成子区域。

示例性的，复杂数据的数据结构为三层指针嵌套结构，则可以基于复杂数据内存申请请求先从目标区域中确定与复杂数据中的第一层指针对应的第一子区域，并保存第一子区域的第一首地址。然后可以基于复杂数据内存申请请求从目标区域中确定与第1+1层，即第2层指针对应的第二子区域，并将第二子区域的第二首地址存储至第一首地址对应的第一子区域中。然后可以将第二子区域作为新的第一子区域，将第二首地址作为新的第一首地址，并基于复杂数据内存申请请求从目标区域中确定与第2+1层，即第3层指针对应的第二子区域，并将第3层指针对应的第二子区域的第二首地址存储至新的第一首地址对应的新的第一子区域中。

此外，复杂数据内存申请请求中还可以包含复杂数据待占用的内存空间大小。然后可以基于复杂数据内存申请请求从目标区域中确定与待占用的内存空间大小对应的区域，第一进程还可以根据复杂数据的数据结构从与待占用的内存空间大小对应的区域中确定子区域。

S1004：通过第一进程将复杂数据存储至子区域，并根据区域关联后的第一进程以及第二进程实现复杂数据的共享操作。

在本实施例中，在申请到复杂数据对应的子区域之后，可以通过第一进程将复杂数据存储至子区域中，即通过子区域的首地址将复杂数据存储至子区域中，然后可以根据区域关联后的第一进程以及第二进程实现复杂数据的共享操作，即第一进程以及第二进程均可以实现对子区域中的复杂数据的读取、修改等操作。

此外，图11为本申请实施例提供的复杂数据共享过程的原理示意图，如图11所示，在该实施例中，第一进程(也可称为服务进程1)需要将复杂数据共享给第二进程(也可称为进程2)，进程2在授信通过的情况下可以获得复杂数据的指针，然后在进程2访问该复杂数据时，复杂数据中包含的多级指针内容均可以直接访问，不需要做地址转换。对应的，进程1需要共享一段包含三级指针的复杂结构的复杂数据，首先需要在用户态共享地址空间申请一段内存region(即目标区域)，然后映射到进程1，进程1可以将复杂结构的复杂数据加载到region内存空间，复杂数据结构的多级指针对应的复杂数据均可以存放在该region区域，进程1保存该复杂数据的首地址指针，默认region内存空间仅可以供本进程1访问。此外，业务上存在关联的其他进程2，可以先通过传统IPC方式向进程1申请region区域的访问权限，权限校验通过后进程2可以获得region区域的相关信息，并在进程2建立region区域的相同的“虚拟地址”和“物理地址”的映射关系，进程2可以直接用与进程1相同的虚拟地址访问共享的复杂数据。另外，复杂数据的二、三级指针在两个进程中也是相同的，进程2获取到复杂数据结构首地址后，就能直接获取到二、三级指针，不需要再次进行虚拟地址转换，有效提高了复杂数据的获取效率。此外，两个进程在初始化或者运行过程中建立好region区域的关联后，后续需要共享的其它数据均可在该region中申请出，不需要每次数据交互都进行地址转换和映射，提高了效率。其中，虚拟地址的跨进程传递或者同步方法，可以灵活使用操作系统里常用的各种IPC方法，如socket，pipe，shmem，ioctl等，还可以通过第一进程提供的API直接操作，或者通过映射好的目标区域提前约定的共享object来访问，且该方式适合频繁通信，且能事先约定的共享数据，在此不再详细进行论述。

此外，若其它进程需要关联进程1，但是授权检测未通过，则不能访问进程1的region区域，提高了数据的安全性。

采用上述方案后，可以将第二进程与第一进程对应的用户态共享地址空间内的目标区域进行关联处理，关联处理后第二进程的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致，然后可以接收第一进程发送的包含复杂数据的数据结构的复杂数据内存申请请求，并基于复杂数据内存申请请求从目标区域中确定与复杂数据的数据结构对应的子区域，再通过第一进程将复杂数据存储至子区域，并根据区域关联后的第一进程以及第二进程实现复杂数据的共享操作。通过将复杂数据存储于第一进程以及第二进程均可以直接访问的子区域中，避免了复杂数据交互过程中繁琐的操作步骤，提高了复杂数据交互的效率，进而保证了服务的实现效果。

此外，在另一实施例中，所述将第二进程与第一进程对应的目标区域进行关联处理，可以包括：

在所述第二进程授权检测通过后，将第二进程与第一进程对应的目标区域进行关联处理。

在本实施例中，在将第二进程与第一进程对应的目标区域进行关联处理时，可以先检测第二进程的权限信息，并在第二进程授权检测通过后，可以将第二进程与第一进程对应的目标区域进行关联处理，提高了待访问复杂数据的安全性。若第二进程的授权检测没有通过，则可以生成检测未通过提示，进而提醒相关人员进行后续处理，提高了处理过程的灵活性。此外，授权检测过程可以采用现有的方式进行，在此不再详细进行论述。

此外，在另一实施例中，图12为本申请实施例提供的多进程间复杂数据的内存分布示意图，如图12所示，在该实施例中，进程的用户态代码可以调用posix标准的内存申请函数(如malloc函数)，返回的虚拟地址落在“用户态普通地址空间”地址空间区域，该用法与常规操作系统的方法无差别，保持良好的兼容性。还可以提供非posix标准的内存申请函数，进程的用户态代码调用此类内存申请函数，返回的虚拟地址落在自己进程所申请的“用户态共享地址空间”地址空间区域内。系统的内存申请函数(如kmalloc，devm_alloc等等)，可以通过flags标志区分用户态普通地址空间或者预留地址空间的申请来源，如当flags不设置或者设置为普通内存申请时，返回普通地址空间虚拟内存。当驱动进程1设置flags为从预留空间申请时，可以调用kmalloc返回的虚拟地址则落在“R1”的区域内，且当驱动程序需要共享一些变量或者数据时，kmalloc申请的内容可以直接共享，不需要进行内存申请函数的替换，减少驱动程序开发和移植的工作量。此外，还可以提供kmalloc对应预留空间的初始化接口，如果需要kmalloc支持flags从预留空间申请一些可配置能力，则可先调用初始化接口，设置kmalloc使用的预留空间的大小、是否能共享等配置。驱动进程1的共享数据在用户态预留空间R1申请出来之后，驱动进程2和3需要共享该数据，申请关联并进行映射后，驱动进程2和3对R1区域就可以直接访问，实现一个region区域可以多个进程关联。驱动进程2可以申请R2以共享数据，驱动进程3可以关联R2，同时驱动进程2也可以关联R1，实现一个进程可以同时关联多个Region。驱动进程3申请R3，但并没有关联给其它进程使用，R3为进程3独占，可保证R3中数据安全性。

图13为本申请实施例提供的复杂数据访问过程的原理示意图，如图13所示，在该实施例中，主要涉及到第一进程、第二进程以及x space管理单元之间的交互过程，第一进程需要共享与汽车相关的目标业务的数据，可以先向x space管理单元申请一块大小为size的目标区域，x space管理单元可以在用户态共享地址空间创建一个页对齐的目标区域，并返回区域编号和目标区域对应的虚拟地址。第一进程还可以申请该目标区域的物理地址映射，xspace管理单元负责将目标区域内一段或多段大小为size1(size1小于或等于size)的空间与大小为size1的物理地址进行映射并返回物理地址。后续可以通过非系统内存申请函数xx_malloc来申请复杂数据结构的相关内存，或者通过该方案提供的初始化接口进行region参数配置和申请，将这块region作为kmalloc申请空间的备选内存，后续可以统一将共享资源内存申请的函数称为x_malloc。其中，如果申请多段空间，多段虚拟地址都需要让关联进程知道，通过API，或者保存在关联操作时获取到的预先约定的object结构体中。

此外，第二进程若需要跟第一进程数据共享，则需要关联目标区域。首先第二进程可以通过IPC的方式来获得第一进程的目标区域的区域编号，然后向x space管理单元申请关联该目标区域，x space管理单元完成第二进程跟目标区域的关联和映射，x space管理单元会在第二个进程关联目标区域时，将目标区域中size1大小的物理地址和虚拟地址映射成跟第一个进程一致，此时，第一进程和第二进程对目标区域的内存可以直接访问，可完成后续一系列数据的交互操作。第一进程若需要将一个复杂结构的复杂数据通过ioctl共享给第二进程，可以先通过x_malloc接口申请复杂数据结构的内存空间并保存其首地址vaddr1，然后依次通过x_malloc申请二级以及三级指针对应的内存空间并保存到前一级指针的对应的地址指向的数据结构中，得到复杂数据对应的子区域。此外，这些x_malloc申请的内存空间均需要从目标区域中申请。在申请完子区域之后，第一进程可以将复杂数据填充至子区域。还可以通过IPC方式发起ioctl命令，将存储复杂数据的数据结构的首地址的值传递给第二进程，并通过cmd标识是复杂数据的数据传递。第二进程接收到ioctl命令后，可以获取到第一进程共享的复杂数据的首地址vaddr1，第二进程即可根据首地址以及复杂数据标识对该共享数据进行读写操作。

综上，通过在微内核架构操作系统上模拟出了一个linux的内核空间，但这个空间又是在用户态空间，默认各个进程独立，保留了微内核的安全性；可以根据需要，授权业务相关联的进程可以共享这个空间，这个空间的虚拟地址能够直接访问，因此复杂结构的数据也能够直接访问，不需要进行多次地址转换等耗时的操作，具有宏内核直接访问的高效率和便利性，一些性能要求的复杂数据的共享可以采用该方法。同时一些系统的内存申请函数可以兼容普通内存空间和特殊预留空间的内存申请，像linux的驱动代码，能很方便地进行移植。此外，在编写软件过程中，可以根据具体业务情况，只把进程中的一部分数据，共享给到指定的进程，提高了复杂数据的安全性。即本申请基于一种特殊地址空间的管理方法，该方法在用户空间预留一块特殊的空间，该地址空间的特点是，不同的进程对该空间同一块内存区域映射后的虚拟地址是相同的，且可以直接访问，基于以上特殊的内存管理方法，提供一种进程间复杂数据结构的数据跨进程共享的方法，使得跨进程的数据传递同时具有宏内核的高效、简单的优点，也保持微内核的进程隔离、功能安全的特性。此外，通过不同进程的虚拟地址的一致性映射，实现一种进程间复杂数据结构的跨进程共享的方法，像ioctl这种常用命令的含多级指针的复杂数据结构的数据传递，采用本发明效率将得到有效提升，可以扩展到其它进程间复杂数据结构数据的共享。同时本发明使系统的内存申请函数可兼容普通内存和特殊预留空间的内存申请，简化驱动移植工作量。

此外，在微内核操作系统中，不同服务进程(例如，系统服务进程、驱动服务进程等)可以运行在独立的用户态进程空间内，以满足功能安全需求。因为进程隔离，一个服务进程对外提供业务时，往往采用RPC(Remote Procedure Call，跨进程的远程过程调用)，图14为现有技术中远程过程调用的原理示意图，如图14所示，A进程对外(如对B进程)提供业务时，调用一个RPC函数，需要把函数名称及函数参数，经过一系列的处理(序列化、协议组装)，然后再传送到另一个进程B中，由B进程进行接收、解析、反序列化、执行等一系列操作。B进程执行结果返回，也需要经过同样的一系列操作传送给A进程。此外，若用户应用程序需要访问驱动进程X，驱动进程X又需要访问驱动进程Y，一次访问操作，就需要至少2次RPC调用，降低了实现效率，尤其是对于一些性能要求较高的场景，无法满足性能的要求。

基于上述技术问题，图15为本申请另一实施例提供的进程间数据共享方法的流程示意图，如图15所示，在该实施例中，操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，所述方法包括：

S1501：确定第一进程对应的目标区域，以及目标区域的虚拟地址和物理地址，其中，目标区域为用户态共享地址空间内的区域，第一进程为服务进程。

在本实施例中，第一进程可以为服务进程，即可以为其他进程提供服务的进程，可以通过该服务进程为其他进程提供数据、锁、寄存器等共享资源。示例性的，第一进程可以为驱动进程，用于提供驱动服务，也可以为其它应用系统服务或者应用程序。

此外，可以自动或依据请求为第一进程分配在用户态共享地址空间内的目标区域(即region区域)，即x space管理单元可以在x space空间创建一个页对齐的region区域，并返回区域编号(也可称为region id)和目标区域对应的虚拟地址。另外，初始化目标区域的引用计数可以为1。

此外，还可以为目标区域分配物理地址。

进一步的，为所述目标区域分配虚拟地址和物理地址，可以包括：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程。

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

具体的，在为第一进程的目标区域分配了区域编号和虚拟地址之后，可以继续为区域编号对应的该目标区域分配物理地址。此外，x space管理单元可以支持在目标区域内，以更小粒度地进行“虚拟地址”和“物理地址”的映射关系的建立及解除。示例性的，可以以pages粒度(4KB的整数倍，最小为4KB)地将物理空间和目标区域内的虚拟空间建立映射关系。

更进一步的，所述根据所述映射请求为所述区域编号对应的目标区域分配物理地址，可以包括：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

具体的，在为目标区域分配物理地址时，可以有多种分配方式。可选的，可以根据映射请求为区域编号对应的目标区域分配连续的物理地址，或者分配非连续的物理地址。可选的，物理地址的起始地址可以为随机分配的或指定的。可选的，还可以指定具体设备的物理空间(即物理地址)与虚拟空间建立映射关系。

综上，增加了虚拟地址和物理地址选择方式的灵活性。

S1502：将第二进程与第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致。

在本实施例中，用于应用第一进程对应的服务的一个或多个第二进程(也可称为客户进程)可以向内存管理单元发送关联请求，用于关联第一进程申请的目标区域。然后可以根据第二进程发送的关联请求，将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，以使关联处理后的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致，通过该方式，即可实现第二进程对目标区域的访问。

进一步的，接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，可以包括：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号。

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

具体的，第二进程发送的关联请求中可以包含区域编号，该区域编号为第一进程申请的目标区域对应的编号，然后可以根据关联请求将第二进程对应的关联区域与区域编号对应的目标区域进行关联处理。

此外，第二进程可以通过IPC的方式来获得第一进程的区域编号，在此不再详细进行论述。

S1503：从目标区域中确定目标子区域，并将第一进程对应的服务的共享资源存储至目标子区域。

在本实施例中，在确定目标区域之后，可以从目标区域中确定目标子区域，然后可以将第一进程对应的服务的共享资源存储至目标子区域中。其中，共享资源可以为频繁访问的或者对读写性能要求比较高的资源。示例性的，第一进程对应的服务可以为驱动服务，共享资源可以为锁数据、业务数据以及寄存器。

此外，若存在预先约定好的共享数据的内存申请，也可以在关联之前从目标区域中确定目标子区域，并将第一进程对应的服务的共享资源存储至目标子区域。示例性的，GPIO的管脚分配和设置，可以提前将管脚的地址空间申请好，第二进程获取到授权的管脚信息后，可以直接设置。

S1504：根据第一进程和/或第二进程发送的调用请求从目标子区域中获取共享资源，并根据共享资源实现服务。

在本实施例中，在将共享资源存储至目标子区域之后，对目标子区域有访问权限的第一进程以及第二进程均可以从目标子区域中获取共享资源，并根据共享资源中包含的业务数据、锁数据以及寄存器等实现对应的服务。示例性的，可以根据共享资源中包含的业务数据、锁数据以及寄存器实现驱动服务。

进一步的，所述根据所述第一进程和/或所述第二进程发送的调用请求从所述目标子区域中获取所述共享资源，具体可以包括：

根据所述第一进程和/或所述第二进程发送的调用请求中包含的目标库从所述目标子区域中获取所述共享资源，其中，所述目标库为所述第一进程提供的用于直接调用所述共享资源的lib库。

或者，根据所述第一进程和/或所述第二进程发送的调用请求中包含的目标虚拟地址从所述目标子区域中获取所述共享资源，其中，所述目标虚拟地址为所述目标子区域的地址。

具体的，在第一进程以及第二进程从目标子区域中获取共享资源时，可以有多种方式。可选的，第一进程可以将与共享资源有关的调用方法、关键数据的定义等细节封装成目标库，以供第二进程调用，第二进程可以将该目标库编译到本进程，然后通过目标库提供的调用方法，直接、透明地调用第一进程提供的服务。示例性的，目标库可以为lib库。综上，第二进程操作共享资源时无需通过进程调用，通过lib库封装的操作共享资源的操作方法，无需了解服务进程A的操作细节，简化了操作过程，提高了操作效率。

可选的，第一进程还可能不提供目标库。在第一进程不提供目标库的情况下，可以在确定存储共享资源的目标子区域之后，将目标子区域的地址通过传统的IPC的方式发送给第二进程，第二进程可以根据该目标子区域的地址从目标子区域中获取共享资源。

图16为本申请实施例提供的服务进程应用的原理示意图，如图16所示，在该实施例中，第一进程可以为服务进程A(即一般需要提供共享资源(锁、数据、寄存器等)给其它进程使用的服务进程，可作为server进程)，第二进程可以为具有目标区域访问权限的授信进程B(即需要使用共享资源的进程，可称作client进程)，普通进程C为不具有目标区域访问权限的进程。此外，多个进程的相互共享关系也可以简化成server-client的关系，也就是说一个进程可以是client进程，同时也可以是server进程。具体实现过程可以为：操作系统内核的内存管理单元需要在用户态共享地址空间内预留部分空间，保证其虚拟地址空间在不同进程间是一致的且授权后能直接访问的。进程A和B、进程A和C之间存在普通的RPC通信，可以进行正常的进程间数据传输。为了提高进程间通信效率，进程A需要将一些频繁访问的或者对读写性能要求比较高的资源进行共享，进程B需要访问这些共享资源。同时系统还可以加入授信管理，把client进程分成授信进程和普通进程，授信进程可以同时使用RPC及“直接调用”方法，非授信进程只能使用传统的RPC方法。

其中，服务进程A作为服务进程，需要完成以下操作：在进程A进程初始化的时候可以申请一段大小为size的目标区域region，并完成region在进程A的虚拟地址以及物理地址的映射。初始化跨进程共享资源(如锁、数据、寄存器等)的时候需要从该目标区域内存中申请，共享资源的虚拟地址就自然映射到目标区域中，便于其它进程直接访问。此外，服务进程A可以直接正常使用这些共享资源来编写驱动程序。此外，服务进程A可以对外提供lib库，把跨进程共享资源的调用方法，关键数据的定义等细节，封装在库里，以供授权检测通过的其他进程直接调用。

此外，进程B作为授信进程，需要完成以下操作：进程B进行授信检测，如果检测通过可以通过传统的IPC方案，获取到服务进程A的目标区域的相关信息，同时将目标区域映射到进程B，则进程B拥有进程A在该目标区域一致的虚拟地址和物理地址，该目标区域的虚拟地址进程B就可以直接访问。授信进程B可以将服务进程A提供的lib库编译到本进程(如果lib库提供的情况下)，然后通过库提供的调用方法(调用方法需同时传入目标区域的标识信息)，直接、透明地调用服务进程提供的服务。如果没有通过lib库提供共享资源的调用方法，则可以在获取目标区域相关信息的时候将共享资源的虚拟地址一并返回给授信进程B，基于此，服务进程A和授信进程B则可以直接对目标区域进行访问。而普通进程C可以通过传统的RPC的方式与服务进程A进行交互，进而实现相关的服务。

采用上述方案后，可以先确定第一进程对应的用户态共享地址空间的目标区域，以及目标区域的虚拟地址和物理地址，该第一进程为服务进程，然后可以将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，使得关联处理后的关联区域的虚拟地址与目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与目标区域的物理地址一致，然后可以从目标区域中确定目标子区域，并将第一进程对应的服务的共享资源存储至目标子区域，进而可以根据第一进程和/或第二进程发送的调用请求从目标子区域中获取共享资源，并根据该共享资源实现服务，通过将服务进程的共享资源存储至目标子区域中，使得第一进程以及授权通过的第二进程均可以直接访问该共享资源，简化了资源的共享过程，提高了数据交互的效率，进而保证了服务的实现效果。

此外，在另一实施例中，所述目标区域有多个，不同的目标区域中存储有不同类型的共享资源，所述将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，可以包括：

根据目标类型将所述第二进程对应的关联区域与第一进程对应的至少一目标区域进行关联处理。

在本实施例中，支持一个服务进程可以有多个授信进程的场景，还可以支持一个服务进程提供多个独立的服务，且不同的服务关联到不同的目标区域，授信进程可以只关联服务进程指定的目标区域。即目标区域可以有多个，不同的目标区域可以存储不同类型的服务对应的共享资源，进而提高了各服务对应的共享资源的安全性。

此外，目标类型可以根据具体应用场景进行划分，示例性的，驱动服务有几组寄存器，对应不同的功能，是为不同的授信进程服务的，可以把这几组寄存器放到不同的目标区域，即可以根据寄存器的功能进行分类。此外，也可以按其它类型分，在此不再详细进行限定。

综上，通过目标类型的设置，提高了共享资源的安全性。

图17为本申请实施例提供的多个目标区域的应用示意图，如图17所示，在该实施例中，驱动程序作为服务进程，可以提供共享资源给多个授信驱动进程使用，为了提高共享资源的安全性，可以将共享资源最小化分类。即不同的授信进程访问的共享资源可以做分类，服务进程初始化的时候可以根据分类好的共享资源创建出多个目标区域(即region)，不同类的共享资源对应不同的目标区域。例如，授信进程1只需要关联region1，授信进程如果只用到region2中的共享资源只需关联region2，如果region1和region2的共享资源都需要使用，则可同时关联到region1和region2，提高了共享资源存储的安全性和灵活性。

在另一实施例中，在所述根据所述第一进程和/或所述第二进程发送的调用请求从所述目标子区域中获取所述共享资源之后，还可以包括：

接收所述第二进程发送的更新请求，其中，所述更新请求中包含待更新数据。

根据所述更新请求为所述第二进程获取资源锁权限，以保护所述第二进程实现所述待更新数据的更新。

通过信号量Semaphore机制，或远程过程调用协议发送更新完成提示至所述第一进程，以实现所述待更新数据的同步。

在本实施例中，在多个进程均有共享资源的访问权限时，一般会涉及到共享资源同步的问题，为了更好的实现共享资源的同步处理，可以采用对共享资源的读写进行加锁保护来实现。此外，还可以采用Semaphore信号量机制或者RPC方式来实现共享资源的同步处理。

可选的，在采用Semaphore信号量机制来实现共享资源的同步时，可以先接收第二进程发送的包含待更新数据的更新请求，然后获取共享的锁资源，在获得共享资源锁使用权限后，可以根据该更新请求对待更新数据进行更新处理，然后可以通过信号量Semaphore机制发送更新完成提示至第一进程，以实现待更新数据的同步通知。此外，第一进程也可以对待更新数据进行更新，即可以先接收第一进程发送的包含待更新数据的更新请求，然后获取共享的锁资源，在获得共享资源锁使用权限后，可以根据该更新请求对待更新数据进行更新处理。然后可以通过信号量Semaphore机制发送更新完成提示至第二进程，以实现待更新数据的同步通知。

示例性的，图18为本申请实施例提供的共享资源同步的应用示意图，如图18所示，在该实施例中，服务进程和授信进程可以通过take或者give semaphore的方式即可实现同步，因为两个进程均会访问该信号量，需要在目标区域中申请出内存，保存内核创建的信号量地址(需要保证可进程共享的信号量)，在等待同步信号量的进程时需要启用一个线程task，睡眠等待同步信号的到来。例如，授信驱动进程对共享资源中的数据进行了更新，并可以在更新完成之后发送(give)一sem信号至服务驱动进程，服务驱动进程可以在接收(take)到sem信号之后唤醒预设的task任务，进而实现更新数据后的进一步操作。

可选的，在采用RPC方式来实现共享资源的同步处理时，当其中一个进程更改了共享资源时，可以通过进程间通信将同步信息传递给对方进程，如使用ioctl命令，对方进程收到ioctl命令后，解析出是共享资源修改同步信息，然后可以根据该同步信息实现共享资源数据更新后的进一步处理。

图19为本申请实施例提供的共享资源同步的时序流程图，如图19所示，在该实施例中，可以对驱动程序中的寄存器Reg32的bit0位进行读写操作，且假设寄存器的改写需要同步通知到该驱动程序，则服务进程，即驱动进程(还可以称为server driver或第一进程)和授权进程(还可以称为client driver或第二进程)的实现过程可以为：服务进程可以先于授权进程完成初始化，或者授权进程在系统完成所有模块初始化后在运行过程中去查询服务进程，或者服务进程初始化完成后通知到授权进程，方式不做限定，只要保证在授权进程去请求目标区域时，服务进程已经完成了目标区域和共享数据的初始化等操作。

授权进程去请求目标区域时，可以通过RPC进程间通信的方式来实现。本示例中目标区域创建后的存储和管理都是服务进程完成的，所以需要在服务进程中开辟一个RPC通道进行通信。此外，也可以采用一个独立的目标区域管理进程来专门管理各服务进程的目标区域信息，该管理进程可以开辟一个RPC通道进行通信，所有授权进程在请求目标区域时可以通过管理进程来获取。授权进程改写寄存器后需要同步通知到服务进程，本示例可以采用sem机制的方式来进行同步，也可以通过ioctl ops的方式来同步。

综上，服务进程在完成RPC通道初始化之后，会创建通道收到RPC消息后的处理task，例如，可以为RPC process task，可以用来处理目标区域的操作以及授权检测过程。

服务进程还可以去预留空间申请一段大小为size的目标区域，同时完成该目标区域的物理地址映射虚拟地址的映射操作，后续本进程就可以直接在该目标区域申请地址空间和读写该地址空间。目标区域创建并初始化完成后，需要在本进程创建一个目标区域对象，里面可以包含该目标区域的相关信息，如大小、区域编号、区域名称、目标区域的私有数据、对象链表等信息，同时会保存到本进程的目标区域列表中，目标区域列表可以同时维护多个目标区域的信息。服务进程在目标区域准备好之后，可以在目标区域申请共享资源需要的目标子区域，例如，sem信号、锁资源、Reg_32等变量需要的空间，返回的地址是特殊的，其它授权进程可直接访问且映射后地址一致的虚拟地址。目标区域可以维护一个对象链表，该链表主要可以保存该进程在该目标区域需要共享的资源对象，即共享资源。还提供资源对象存取操作函数(export和import obj函数)，例如，export函数将每个资源对象(这里是sem、lock、Reg_32的虚拟地址)依次保存到对象链表中(其中，该对象链表也是从目标区域申请出来的)。

此外，服务进程可以将共享资源对象的操作封装成目标库(可以为lib库)供授权进程直接引用，共享资源对象也可以保存到目标区域对应的私有数据(例如，priv_data)中去，或者通过import_obj(region_ctx，name)接口直接获取到共享资源对象的地址进行访问。服务进程在Reg_32寄存器被改写后，可以通过sem机制的方式进行同步。具体的，服务进程可以先创建一个sem take的task任务，用来处理sem同步信号take到的后续操作(此外，服务进程在改写共享资源时，可以通知client进程同步知晓，client进程也可以通过创建一个sem take task任务，并通过另一sem信号量来同步，或者通过ioctl命令来通知)。服务进程还可以继续使用共享资源对象完成本驱动程序需要完成的其它工作，然后开始正常运行等待其它进程的访问。授权进程完成自身的初始化后如果需要访问共享资源对象，首先需要去服务进程获取目标区域相关信息，可以通过RPC通信去获取，request接口同时会进行授权校验(授权校验的时机不一定跟request接口耦合，只要在client进程访问region之前完成校验即可，不做限制)，检验通过后则可以对目标区域进行授信进程的映射操作，后续则可以直接访问该目标区域的虚拟地址。

此外，授信进程可以调用目标库的Get_Reg32_bit0(region_ctx)接口，该接口可以首先从对象链表中获取(import)锁资源，Reg_32寄存器等对象的地址，然后可以读出Reg_32中bit0的值。锁资源可以完成本进程或者服务进程与授信进程间共享资源读写的互斥，示例性的，可以为mutex lock，该锁必须是进程间可共享的，所以需要从内核中申请，保存锁的地址空间需要从目标区域中申请。当授信进程需要设置Reg_32寄存器中bit0时，可以调用目标库的Set_Reg32_bit0(region_ctx)接口，该接口可以从对象链表中获取(import)锁资源，Reg_32、sem等对象的地址，锁住共享资源Reg_32，完成bit0的设置后，give sem信号量，然后解锁，预存的sem take task会被唤醒，并继续完成后续操作。此外，授信进程也可以在目标区域申请内存，进行读写操作；也可以通过RPC或者利用共享地址空间将本进程申请的目标区域的内存地址传递给服务进程。

综上，本申请结合了微内核和宏内核的优点，实现了一个服务进程可以通过传统的RPC对其它进程提供服务，也可以用类似宏内核的方法提供跨进程“直接服务”的方法，其它进程通过共享数据和共享锁、信号量同步等方式，和驱动服务进程协调工作，无需进程切换。既有宏内核高效、简单的优点，也保持微内核的进程隔离、功能安全的特性。即通过直接内存访问的方式进行交互，对其它进程间的关键数据交互同样适用。

此外，本申请还可以使系统的内存申请函数兼容普通内存和特殊预留空间的内存申请，简化驱动移植工作量。

基于同样的思路，本说明书实施例还提供了上述方法对应的装置，图20为本申请实施例提供的进程间数据共享装置的结构示意图，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，如图20所示，本实施例提供的装置，可以包括：

接收模块2001，用于接收第一进程发送的共享区域申请请求，其中，所述共享区域申请请求用于申请所述用户态共享地址空间内的区域，所述共享区域申请请求中包含待占用区域的内存大小。

处理模块2002，用于基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，并为所述目标区域分配虚拟地址和物理地址。

在本实施例中，所述处理模块2002，还用于：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域。

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

进一步的，所述处理模块2002，还用于：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程。

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

更进一步的，所述处理模块2002，还用于：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

所述处理模块2002，还用于接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

所述处理模块2002，还用于根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

在另一实施例中，所述处理模块2002，还用于：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号。

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

在另一实施例中，在进程申请或关联所述目标区域之后，所述目标区域的引用个数会对应增加一个，所述处理模块2002，还用于：

接收所述第一进程和/或所述第二进程发送的解除请求。

根据所述解除请求对所述第一进程和/或所述第二进程，与所述目标区域进行关联解除处理。

将所述引用个数减一，得到新的引用个数。

此外，所述处理模块2002，还用于：

若所述新的引用个数为零，则释放所述目标区域。

本申请实施例提供的装置，可以实现上述如图2所示的实施例的方法，其实现原理和技术效果类似，此处不再赘述。

此外，本申请另一实施例提供了一种进程间数据共享装置，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，本实施例提供的装置，可以包括：

处理模块，用于将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，其中，所述目标区域为所述用户态共享地址空间内的区域，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

在本实施例中，所述处理模块，还用于：

接收第一进程发送的共享区域申请请求，并根据所述共享区域申请请求为所述第一进程分配与待占用区域的内存大小对应的目标区域。

为所述目标区域分配虚拟地址和物理地址。

接收第二进程发送的关联请求，并根据所述关联请求将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，其中，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

更进一步的，所述处理模块，还用于：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域。

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

进一步的，所述处理模块，还用于：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程。

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

接收模块，用于接收所述第一进程发送的复杂数据内存申请请求，其中，所述复杂数据内存申请请求中包含复杂数据的数据结构。

所述处理模块，还用于基于所述复杂数据内存申请请求从所述目标区域中确定与所述复杂数据的数据结构对应的子区域。

进一步的，所述复杂数据的数据结构为多层指针嵌套结构，所述处理模块，还用于：

基于所述复杂数据内存申请请求从所述目标区域中确定与所述复杂数据中的第N层指针对应的第一子区域，并保存所述第一子区域的第一首地址，其中，N为自然数，且小于或等于所述多层指针嵌套结构的指针层数。

基于所述复杂数据内存申请请求从所述目标区域中确定与第N+1层指针对应的第二子区域，并将所述第二子区域的第二首地址存储至所述第一首地址对应的第一子区域中，其中，所述第一子区域与所述第二子区域均属于所述子区域。

所述处理模块，还用于通过所述第一进程将复杂数据存储至所述子区域，并根据区域关联后的第一进程以及第二进程实现所述复杂数据的共享操作。

此外，在另一实施例中，所述处理模块，还用于：

接收所述第一进程和/或所述第二进程发送的解除请求。

根据所述解除请求对所述第一进程和/或所述第二进程，与所述目标区域进行关联解除处理。

将所述引用个数减一，得到新的引用个数。

若所述新的引用个数为零，则释放所述目标区域。

在本实施例中，所述处理模块，还用于：

在所述第二进程授权检测通过后，将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理。

此外，本申请另一实施例提供了一种进程间数据共享装置，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，本实施例提供的装置，可以包括：

确定模块，用于确定所述第一进程对应的目标区域，以及所述目标区域的虚拟地址和物理地址，其中，所述目标区域为所述用户态共享地址空间内的区域，所述第一进程为服务进程。

处理模块，用于将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，其中，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

所述处理模块，还用于从所述目标区域中确定目标子区域，并将所述第一进程对应的服务的共享资源存储至所述目标子区域，其中，所述共享资源包括所述服务实现过程中涉及到的锁数据、业务数据以及寄存器中的至少一种。

所述处理模块，还用于根据所述第一进程和/或所述第二进程发送的调用请求从所述目标子区域中获取所述共享资源，并根据所述共享资源实现所述服务。

在本实施例中，所述处理模块，还用于：

根据所述第一进程和/或所述第二进程发送的调用请求中包含的目标库从所述目标子区域中获取所述共享资源，其中，所述目标库为所述第一进程提供的用于直接调用所述共享资源的lib库。

或者，根据所述第一进程和/或所述第二进程发送的调用请求中包含的目标虚拟地址从所述目标子区域中获取所述共享资源，其中，所述目标虚拟地址为所述目标子区域的地址。

在另一实施例中，所述目标区域有多个，不同的目标区域中存储有不同类型的共享资源，所述处理模块，还用于：

根据目标类型将所述第二进程对应的关联区域与第一进程对应的至少一目标区域进行关联处理。

在另一实施例中，所述处理模块，还用于：

接收所述第二进程发送的更新请求，其中，所述更新请求中包含待更新数据。

根据所述更新请求为所述第二进程获取资源锁权限，以保护所述第二进程实现所述待更新数据的更新。

通过信号量Semaphore机制，或远程过程调用协议发送更新完成提示至所述第一进程，以实现所述待更新数据的同步。

在另一实施例中，所述处理模块，还用于：

接收第一进程发送的共享区域申请请求，并根据所述共享区域申请请求为所述第一进程分配与待占用区域的内存大小对应的目标区域。

为所述目标区域分配虚拟地址和物理地址。

接收第二进程发送的关联请求，并根据所述关联请求将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理，其中，关联处理后的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致。

在本实施例中，所述处理模块，还用于：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域。

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

此外，在另一实施例中，所述处理模块，还用于：

在所述第二进程授权检测通过后，将第二进程对应的关联区域与第一进程对应的目标区域进行关联处理。

图21为本申请实施例提供的电子设备的硬件结构示意图，如图21所示，本实施例提供的设备2100包括：处理器2101，以及与所述处理器通信连接的存储器。其中，处理器2101、存储器2102通过总线2103连接。

在具体实现过程中，处理器2101执行所述存储器2102存储的计算机执行指令，使得处理器2101执行上述方法实施例中的方法。

处理器2101的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

在上述的图21所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现上述方法实施例的进程间数据共享方法。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上所述的进程间数据共享方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种进程间数据共享方法，其特征在于，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，所述方法包括：

接收第一进程发送的共享区域申请请求，其中，所述共享区域申请请求用于申请所述用户态共享地址空间内的区域，所述共享区域申请请求中包含待占用区域的内存大小；

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，并为所述目标区域分配虚拟地址和物理地址；

接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致；

根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

2.根据权利要求1所述的方法，其特征在于，所述基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，包括：

基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址随机的目标区域；

或者，基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应，且起始虚拟地址为指定地址的目标区域。

3.根据权利要求1所述的方法，其特征在于，所述为所述目标区域分配虚拟地址和物理地址，包括：

为所述目标区域分配区域编号以及虚拟地址，并将所述区域编号以及虚拟地址返回所述第一进程；

接收所述第一进程发送的包含区域编号以及虚拟地址的映射请求，并根据所述映射请求为所述区域编号对应的目标区域分配物理地址。

4.根据权利要求3所述的方法，其特征在于，所述根据所述映射请求为所述区域编号对应的目标区域分配物理地址，包括：

根据所述映射请求为所述区域编号对应的目标区域分配连续或非连续物理地址，且所述物理地址为随机分配的或指定的。

5.根据权利要求1所述的方法，其特征在于，所述接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，包括：

接收所述第二进程发送的关联请求，其中，所述关联请求中包含区域编号；

根据所述关联请求将所述第二进程对应的关联区域与所述区域编号对应的目标区域进行关联处理。

6.根据权利要求1-5任一项所述的方法，其特征在于，在进程申请或关联所述目标区域之后，所述目标区域的引用个数会对应增加一个，在所述根据区域关联后的第一进程以及第二进程实现数据的共享操作之后，还包括：

接收所述第一进程和/或所述第二进程发送的解除请求；

根据所述解除请求对所述第一进程和/或所述第二进程，与所述目标区域进行关联解除处理；

将所述引用个数减一，得到新的引用个数。

7.根据权利要求6所述的方法，其特征在于，在所述将所述引用个数减一，得到新的引用个数之后，还包括：

若所述新的引用个数为零，则释放所述目标区域。

8.一种进程间数据共享装置，其特征在于，微内核操作系统的内存地址空间分为内核态地址空间和用户态地址空间，用户态地址空间分为用户态普通地址空间和用户态共享地址空间，所述装置包括：

接收模块，用于接收第一进程发送的共享区域申请请求，其中，所述共享区域申请请求用于申请所述用户态共享地址空间内的区域，所述共享区域申请请求中包含待占用区域的内存大小；

处理模块，用于基于所述共享区域申请请求为所述第一进程分配与所述待占用区域的内存大小对应的目标区域，并为所述目标区域分配虚拟地址和物理地址；

所述处理模块，还用于接收第二进程发送的关联请求，并根据所述关联请求将所述第二进程与所述第一进程对应的目标区域进行关联处理，其中，关联处理后第二进程的关联区域的虚拟地址与所述目标区域的虚拟地址一致，关联处理后的关联区域的物理地址与所述目标区域的物理地址一致；

所述处理模块，还用于根据区域关联后的第一进程以及第二进程实现目标业务数据的共享操作，以实现目标业务。

9.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至7任一项所述的进程间数据共享方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至7任一项所述的进程间数据共享方法。

11.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的进程间数据共享方法。