[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2021217529A1 - 一种进程间通信的方法及系统 - Google Patents

一种进程间通信的方法及系统 Download PDF

Info

Publication number
WO2021217529A1
WO2021217529A1 PCT/CN2020/087917 CN2020087917W WO2021217529A1 WO 2021217529 A1 WO2021217529 A1 WO 2021217529A1 CN 2020087917 W CN2020087917 W CN 2020087917W WO 2021217529 A1 WO2021217529 A1 WO 2021217529A1
Authority
WO
WIPO (PCT)
Prior art keywords
ipc
engine
callee
data
address
Prior art date
Application number
PCT/CN2020/087917
Other languages
English (en)
French (fr)
Inventor
张建永
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202080001704.4A priority Critical patent/CN113939805A/zh
Priority to PCT/CN2020/087917 priority patent/WO2021217529A1/zh
Publication of WO2021217529A1 publication Critical patent/WO2021217529A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Definitions

  • Linux-based IPC mechanisms include, for example, pipe communication, signal communication, message queues, and sockets.
  • Android (android) Linux-based kernel provides a further optimized IPC mechanism: IPC binder.
  • Binder is a communication mechanism based on the client-server (Client-server, CS) mode. All clients obtain server-side services through a centralized binder driver.
  • IPC The performance of IPC is a key factor that affects the overall performance of computing devices. For example, for Android, user space processes need to interact frequently with a large number of user space services, and the delay performance of IPC also directly affects user experience.
  • the callee can create the page table of the process and add it to the MMU according to the starting address and length (size) of the shared memory.
  • the page table defines the segment globally The mapping relationship between the virtual address (VA) and the physical address (PA) of the shared memory, the implementation of the solution of the embodiment of this application can also realize that after the IPC engine is initialized, the operating system allocates the shared memory, and the callee initiates registration After that, the page table of this process is established and managed by MMU, so that the purpose of sharing memory between caller and callee is achieved, and changes to the existing MMU workflow are avoided, page faults are avoided, and the stability of IPC communication is ensured. Sex and safety.
  • mapping relationship between the virtual address of msg and the physical address in the memory segment is consistent with the mapping relationship recorded in the page table managed by the MMU, so, In the subsequent IPC communication, after the msg VA is passed from the caller to the callee through the IPC engine, the callee can access the page table to obtain the data according to the VA, thereby achieving the purpose of sharing memory between the caller and the callee, and avoiding the need for existing The change of the MMU workflow to avoid the occurrence of page faults, and to ensure the stability and security of IPC communication.
  • the processor core before running the client process, is further configured to send registration information of the server process to the IPC engine hardware, where the registration information includes The identifier; the IPC engine hardware is also used to: receive the registration information; in response to the registration information, save the identifier and the server process entry address in the IPC engine hardware; the IPC engine The hardware is specifically used to: find the entry address according to the identifier; set the entry address to the program counter (PC) in the processor core; the processor core is also used to, according to the setting in the The entry address in the PC runs the server process.
  • the IPC engine hardware is specifically used to: find the entry address according to the identifier; set the entry address to the program counter (PC) in the processor core; the processor core is also used to, according to the setting in the The entry address in the PC runs the server process.
  • PC program counter
  • the callee register set further includes a first address register and a counting register.
  • the first address register is used to store the first address of the callee list. Specifically, it may be the first callee entry address in the callee list.
  • the counting register is used to record the number of callee entry addresses (entry list size). Specifically, each time a list entry (ie, a callee entry address) is added to the callee list, the number of the count register records is increased by 1. In this way, through the callee register set, the entry address (callee entry address) of multiple callees can be recorded to the callee list according to the registration status of multiple callees.
  • the IPC engine hardware is further configured to, after receiving the call instruction, query the status register in the processor core to obtain the call of the client process Stack address, and save the call stack address of the client process in the IPC engine hardware; the IPC engine hardware is specifically used to call out the call stack address according to the second processor instruction and instruct The processor core resumes running the client process according to the call stack address.
  • the IPC engine can check at least one of the following conditions through the IPC logic circuit:
  • the IPC logic circuit can determine whether the process context information needs to be migrated according to whether the process is in the same core.
  • the call instruction and the return instruction are both user mode instructions. This satisfies the service call of the caller and the callback of the callee, realizes the interaction of the process at the user mode level, avoids the disadvantages of frequent switching between the user mode and the kernel mode in the existing IPC mechanism (such as the binder mechanism), and realizes that the software does not switch to the kernel. Mode, the IPC engine and CPU work in parallel on the hardware.
  • an embodiment of the present application provides a method for inter-process communication IPC.
  • the method in this embodiment is a method executed in the system described in the first aspect.
  • the method includes: when the IPC engine hardware is initialized by the processor core, a part of the memory space in the memory is configured as the shared memory space of the process, and the shared memory space is used to store the data to be transferred required for inter-process communication;
  • the start address and length of the shared memory space establish a page table, the page table contains the virtual address to the physical address mapping relationship of the shared memory space;
  • the processor core runs a client process, and the client process needs When the service of the server process is called, a first processor instruction is sent to the IPC engine hardware.
  • the first processor instruction is a call instruction of the client process to the service, and the call instruction includes the server process
  • the IPC engine hardware instructs the processor core to run the server process according to the identifier and transfers the The virtual address of the data to be transferred is sent to the server process;
  • the processor core runs the server process, and the server process queries the page table according to the virtual address of the data to be transferred to obtain the Data to be transferred to execute the service;
  • the processor core sends a second processor instruction to the IPC engine hardware, the second processor instruction is a return instruction of the server process;
  • the IPC engine hardware is based on The second processor instruction instructs the processor core to resume running the client process.
  • the processor core allocates a part of the shared memory space to the client process when the client process needs to call the service of the server process, To save the data to be transferred.
  • the method further includes: the IPC engine hardware queries the status register in the processor core To obtain the call stack address of the client process, and save the call stack address of the client process in the IPC engine hardware; correspondingly, the IPC engine hardware according to the second processor instruction, Instructing the processor core to resume running the client process includes: the IPC engine hardware calls out the call stack address according to the second processor instruction, and instructs the processor core according to the call stack address Resume the client process.
  • the method further includes: the IPC engine hardware checks the client Whether the client process and the server meet the requirements of inter-process communication; correspondingly, the IPC engine hardware instructs the processor core to run the server process according to the identifier specifically includes: the client process and the server process When the server meets the requirements of inter-process communication, the IPC engine hardware instructs the processor core to run the server process according to the identifier.
  • the call instruction and the return instruction are both user mode instructions.
  • the present application provides a method for inter-process communication IPC, which is applied to an IPC engine in the form of a physical entity (ie, IPC engine hardware); when the IPC engine hardware is initialized, the processor core will A part of the memory space in the memory is configured as the shared memory space of the process, the shared memory space is used to store the data to be transferred required for inter-process communication; the page table is established according to the starting address and length of the shared memory space, the The page table contains the mapping relationship between the virtual address and the physical address of the shared memory space;
  • the processor core allocates a part of the memory space in the shared memory space to the client process, To save the data to be transferred.
  • the method before the IPC engine receives the call instruction from the client process, the method further includes: the IPC engine accepts the registration of the server process; the IPC engine according to The registration of the server process records the identifier of the server process and the entry address of the server process.
  • the IPC engine activating the server process according to the identifier of the server process includes: the IPC engine finds the entry address of the server process according to the identifier of the server process; the IPC engine according to the identifier of the server process; The entry address of the server process runs the server process.
  • the IPC engine after the IPC engine receives the call instruction from the client process, it further includes: the IPC engine records the entry address of the client process; correspondingly, the IPC engine Restoring the client process according to the return instruction includes: the IPC engine switches the operation of the server process to the operation of the client process according to the entry address of the client process.
  • the method further includes: the IPC engine checks the client process and the server process Whether it meets the requirements of inter-process communication; correspondingly, the IPC engine activates the server process according to the identifier of the server process, including: meeting the requirements of inter-process communication between the client process and the server In this case, the IPC engine activates the server process according to the identifier of the server process.
  • the embodiments of the present application also provide IPC engine hardware, which is used to execute the method described in the third aspect, or can realize the function of the IPC engine hardware in the method described in the second aspect.
  • the IPC engine hardware includes an IPC logic circuit (or called IPC logic), callee register set, link register (or link reg), message register set, the IPC engine can be deployed on the CPU core or independently.
  • the IPC engine hardware may be a coprocessor or an independent processing chip.
  • the IPC engine hardware may be integrated in the processor, and the IPC engine hardware and the CPU core run in parallel.
  • the IPC engine hardware may be independent of the processor and communicate through a communication line/interface.
  • this application provides a computer storage medium for storing a computer program, and when the computer program is executed by one or more processors, any one of the second aspect or the third aspect is provided. Methods.
  • the present application provides a computer program product, the computer program product is used to store a computer program, and when the computer program is executed by one or more processors, any one of the second aspect or the third aspect is provided. Methods.
  • Figure 1 is a schematic diagram of a scene of the existing Binder mechanism
  • FIG. 3 is a schematic diagram of another possible application scenario of communication between a client process and a server process based on the CS mode provided by an embodiment of the present application;
  • 4A is a block diagram of a possible system structure of a computing device in an embodiment of the present application.
  • 4B is an example diagram of a physical hardware system provided by an embodiment of the present application.
  • FIG. 5B is an example diagram of some application scenarios of the IPC engine provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an IPC communication scenario using the solution of the present application provided by an embodiment of the present application.
  • At least one refers to one or more, and “multiple” refers to two or more.
  • the character “/” generally indicates that the associated objects before and after are in an “or” relationship.
  • "The following at least one item (a)” or similar expressions refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a).
  • at least one of a, b, or c can mean: a, b, c, "a and b", “a and c", “b and c”, or “a and b and c” ", where a, b, and c can be single or multiple.
  • the client-server (CS) mode involved in the embodiments of the present application is first described below.
  • the requestor of the service can be called the client
  • the implementer of the service can be called the server
  • the process of the client can be referred to as the client process for short
  • the client process is the process that accesses the service.
  • This article can also be referred to as the sender (caller).
  • the server process can be referred to as the server process for short.
  • the server process is a process that provides services, and can also be referred to as a receiving process (callee) in this article.
  • the two processes may also be located on different computing devices, that is, IPC reflects the communication between two different computing devices (computing device 1 and computing device 2), where, The computing device 1 and the computing device 2 may both be terminals, or both may be servers, or one device may be a terminal and the other device may be a server.
  • the operating system type of the computing may be the Android system (Android system).
  • Android system the Android system
  • the inter-process communication method of the present application is applied to the Android system. Examples are explained.
  • caller and callee realize direct IPC communication in user mode, thereby avoiding the delay caused by switching between kernel mode and user mode in the existing scheme, and data between processes
  • the interaction can only transfer the data address (data access right), thereby reducing or even eliminating the occurrence of data copying, greatly improving the efficiency of data transmission, and further reducing the delay of the IPC process.
  • the IPC engine hardware 312 may be a coprocessor or an independent processing chip. In some embodiments, the IPC engine hardware 312 may be integrated in the processor 311, and the IPC engine hardware 312 and the CPU core run in parallel. In still other embodiments, the IPC engine hardware 312 may be independent of the processor 311 and communicate through a communication line/interface. For the specific function implementation of the IPC engine hardware 312, reference may be made to the description of the IPC engine in any embodiment of the present application.
  • the processor 311 may include one or more interfaces.
  • the interface may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (PCM) interface, and a universal asynchronous transceiver (universal asynchronous transceiver) interface.
  • I2C integrated circuit
  • I2S integrated circuit built-in audio
  • PCM pulse code modulation
  • UART universal asynchronous transceiver
  • asynchronous receiver/transmitter, UART mobile industry processor interface
  • MIPI mobile industry processor interface
  • GPIO general-purpose input/output
  • SIM subscriber identity module
  • USB Universal Serial Bus
  • the user interface 314 can be used to connect peripheral devices in the computing device 30, such as various input/output devices (I/O devices, sensors, display screens, etc.), which is not limited in the embodiment of the present application.
  • peripheral devices such as various input/output devices (I/O devices, sensors, display screens, etc.), which is not limited in the embodiment of the present application.
  • the hardware architecture may include IPC logic circuit (or IPC logic), callee register set (also referred to as the second register set), link register (or link reg), message register set (also referred to as It is the first register set), the IPC engine can be deployed on the CPU core or independently.
  • IPC logic circuit or IPC logic
  • callee register set also referred to as the second register set
  • link register or link reg
  • message register set also referred to as It is the first register set
  • the IPC engine can be deployed on the CPU core or independently.
  • the IPC logic circuit can respond to two user mode processor instructions ipccall and ipcret.
  • the ipccall and ipcret are instructions that the process can call in the user mode; control the IPC process and complete the callee Check the various conditions of the caller and so on.
  • the callback entry address includes an address pointer of the service function of the callback.
  • the service function may be a callback function (Callback function), that is, the address pointer of the callback points to the callback function (Callback function) registered by the callback. Address, the callback function is used for callee to execute the corresponding service (service).
  • the callback function belongs to a kind of handler, which is a function called through a function pointer, and the call between functions is realized through the callback function. If the pointer (address) of a function is passed as a parameter to another function, when this pointer is used to call the function pointed to by it, the function is called a callback function.
  • the IPC engine can set the Program Counter (PC) in the CPU to the callee entry address, so that the CPU starts to execute the callee process context and run the callee to execute the corresponding service.
  • PC Program Counter
  • each list entry in the callee list can be configured to correspond to an index identification (ID).
  • ID may be the process ID of the callee (ie callee ID), or the index ID may be one-to-one mapped with the process ID, and the index ID may be determined after the callee is registered with the IPC engine. In this way, it is convenient for the client process (caller) to perform IPC with one or more callees.
  • the IPC engine can find the callee entry address according to the ID passed in by the caller.
  • the call instruction (ipccall) initiated by the caller to the IPC engine carries the callee ID (callee ID).
  • the IPC logic circuit can look up the callee list according to the callee ID and index to the callee.
  • the entry address of the callee (callee entry address).
  • the IPC engine can also set the Program Counter (PC) in the CPU to the callee entry address, so that the callee can run and provide corresponding services.
  • the program counter is a register that holds the address (location) of the instruction currently being executed.
  • the storage address of the program counter is incremented by one. After each instruction is fetched, the program counter points to the next instruction in the sequence. Therefore, the IPC engine can send the callee entry address to the PC for recording, so that the CPU executes the command to run the callee.
  • the user interface of the CPU core can provide system calls such as callee entry address addition (add) and removal (remove), and the registration and deregistration of the callee service can also be done through this Interface implementation.
  • a caller can pass in one or more msg addresses through a call instruction (ipccall).
  • the address of the incoming msg may be a virtual address (VA) of the msg.
  • VA virtual address
  • One or more msg entry addresses can be recorded through the message register set each time. When the message register set records msg entry addresses multiple times, these msg entry addresses can form a list, which can be called a msg list (msg list), and this list can be stored in memory for indexing.
  • the message register set can be regarded as the manager of the msg list, providing functions such as editing (adding, deleting), maintaining, accessing, or querying the msg list.
  • the operating system allocates memory to the caller based on the shared memory, that is, allocates a part of the memory space in the shared memory to the caller to save the data to be transferred (msg), and the virtual address of the data (VA ) Indicates to the caller so that the caller can initiate the call instruction ipccall.
  • the ipccall of the caller can carry msg VA (as shown in the VA1), and the IPC logic circuit of the IPC engine can look up the mapping table corresponding to the shared memory based on the msg VA to determine the PA corresponding to the msg VA (as shown in the figure) PA1), the PA is used as the msg entry address, and the msg entry address to the msg list is recorded through the message register set. It is understandable that when multiple msg VAs are passed into the caller, multiple msg entry addresses can be recorded to the msg list through the message register set.
  • the IPC engine can find the PA by looking up the mapping table according to the incoming msg VA, and record the mapping relationship between the VA and the PA to realize the maintenance of the msg list. In this way, on the one hand, the IPC engine only needs to pass msg and VA to the callee without passing msg itself, avoiding the drawbacks of data replication and improving transmission efficiency.
  • the IPC logic circuit of the IPC engine can control the access authority of msg by setting the query authority of the callee to the msg list maintained by the IPC engine.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种进程间通信的方法及系统，系统包括：处理器核、IPC引擎硬件和存储器，处理器核用于在IPC引擎硬件初始化时将存储器的部分内存空间配置为共享内存空间以保存进程间通信所需的待传递数据，并建立页表；运行客户端进程，向IPC引擎硬件发送调用指令，调用指令包括服务端进程的标识和待传递数据的虚拟地址；待传递数据的物理地址位于共享内存空间；IPC引擎硬件用于指示处理器核运行服务端进程；处理器核运行服务端进程，服务端进程根据待传递数据的虚拟地址查询页表获得待传递数据来执行服务；以及，向IPC引擎硬件发送返回指令；IPC引擎硬件用于指示处理器核恢复运行客户端进程。由此，能够降低IPC时延，提升数据传输效率并提升性能。

Description

一种进程间通信的方法及系统 技术领域
本申请涉及计算机技术领域，尤其涉及一种进程间通信的方法、相关设备以及系统。
背景技术
软件系统，例如Linux中以进程为单位分配和管理资源。在用户空间，一个进程不能直接访问另一个进程的资源。然而，在实际应用中，通常需要使用多个进程来共同完成一项任务，这就要求进程间需要有通信机制，即进程间通信(Inter-process communication，IPC)。IPC为至少两个进程间传送数据或者信号的技术。进程是计算设备分配资源的单元，进程可以运行在同一个计算设备或者网络连接的不同计算设备上。每个进程都对应一部分独立的系统资源，彼此相互隔离，而通过IPC机制能够让不同的进程能够相互访问资源并进行协调工作。
传统方案上，基于Linux的IPC机制例如有管道(pipe)通信、信号通信、消息队列、套接字(socket)等。安卓(android)基于Linux的内核提供了进一步优化的IPC机制：IPC binder。binder是一种基于客户端-服务端(Client-server，CS)模式的通信机制，所有客户端通过中心化的binder驱动来获得服务端的服务。
IPC的性能表现是影响计算设备总体性能的关键因素，比如对于android，用户空间的进程需要与大量的用户空间的服务(service)进行频繁交互，IPC的时延表现也直接影响了用户体验。
例如参见图1，现有的Binder机制的核心是在内核层运行Binder驱动，由于在系统中的内核空间可以进行资源共享的，所以Binder驱动具有强大的跨进程访问能力，Binder驱动承担了客户端(client)的进程(caller)和服务端(server)的进程(callee)之间进行IPC通信的媒介角色。用户态的caller进程通过系统调用函数“call()”请求内核(kernel)服务，caller进程陷入到内核态完成上下文切换，即需要进行用户态到内核态的切换。接下来完成IPC消息数据的拷贝，将消息数据从客户端的用户空间复制到内核空间，而服务端作为数据接受端与内核共享数据，所以不需要再拷贝数据。所以整个IPC过程只需一次内存复制就将消息数据传递到callee。然后，内核切换至用户态的callee的上下文完成服务响应，最后通过调用函数“reply()”返回，内核再恢复caller进程的状态。
上述Binder机制中，一方面，内核需要分配执行时间以完成进程的内核态与用户态的切换和进程上下文的保存/恢复过程，使得IPC过程占用的CPU周期可以长达00 cycle，时延开销大。另一方面，消息数据传递中不可避免地需要一次拷贝过程，影响了数据传输效率。当现有一些解决方案尝试克服上述缺陷时，又往往需要更改现有标准中内存管理单元(Memory Management Unit，MMU)的地址访问流程，难以在遵循现有标准的产品中推广应用。
发明内容
本申请提供了一种进程间通信的方法、相关设备及系统，能够降低IPC时延，提升数 据传输效率并提升性能。
第一方面，本申请提供了一种用于进程间通信IPC的硬件系统，该系统包括：处理器核、IPC引擎硬件和存储器，其中：处理器核用于，在所述IPC引擎硬件初始化时，将所述存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保存进程间通信所需的待传递数据；根据所述共享内存空间的起始地址和长度建立页表，所述页表包含所述共享内存空间的虚拟地址到物理地址的映射关系；处理器核还用于，运行客户端进程(例如caller)，在所述客户端进程需要调用服务端进程(例如callee)的服务时，向所述IPC引擎硬件发送第一处理器指令(例如说明书所描述的ipccall)，所述第一处理器指令是所述客户端进程对所述服务的调用指令，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；所述待传递数据的物理地址位于所述共享内存空间；IPC引擎硬件用于，根据所述标识指示所述处理器核运行所述服务端进程，并将所述待传递数据的虚拟地址发送给所述服务端进程；所述处理器核还用于，运行所述服务端进程，所述服务端进程根据所述待传递数据的虚拟地址查询所述页表获得所述待传递数据来执行所述服务；以及，向所述IPC引擎硬件发送第二处理器指令(例如说明书描述的ipcret)，所述第二处理器指令是所述服务端进程的返回指令；所述IPC引擎硬件还用于，根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程。
其中，客户端进程和服务端进程的属性可以是进程，也可以是线程。
可以看到，本申请实施例可将用户态内的上下文信息保存、上下文切换和恢复、数据传递等从时间和空间上都转移到一个新的物理实体(即IPC引擎)实现。IPC引擎作为IPC的媒介，提供对应的用户态指令ipccall和ipcret，使得caller和callee在用户态就能完成上下文切换，而不用切换到内核态，从而满足了caller的服务调用和callee的回调，实现了进程在用户态层面的交互，IPC引擎可以和内核软件并行工作，极大降低IPC过程的整体时延。另外，在本申请实施例中可以通过IPC引擎进行数据访问权的传递，仅需要传递数据的虚拟地址给callee即可，而不需要传递数据本身，从而避免了对数据的拷贝(copy)，进一步消减了数据拷贝的时延，并提升数据传输效率。
另外，在系统初始化(IPC引擎初始化)时，运行于处理器核的操作系统在物理内存中预留(或称配置)一部分内存作为caller和callee的共享内存。也就是说，本申请实施例中，共享内存是在IPC引擎初始化时固定预留分配的，这部分共享内存不在内核(例如kernel)的page管理页表中。这部分共享内存可由IPC引擎直接访问。该共享内存可用于保存IPC通信过程中需要在进程间传递的数据。通过预留该共享内存，能够建立专用的页表(该页表包含虚拟地址和物理地址的映射关系)，保证待传递数据始终有对应的物理页，从而避免缺页错误，提高系统性能。
共享内存分配后，在callee注册到IPC引擎时，callee可以根据该共享内存的起始地址和长度(size)，建立本进程的页表并添加到MMU中，该页表从全局定义了该段共享内存的虚拟地址(VA)和物理地址(Physical Address,PA)之间的映射关系，实施本申请实施例的方案，还可实现在IPC引擎初始化后，操作系统分配共享内存，且callee发起注册后建立本进程的页表，由MMU管理，从而，既达到了caller和callee共享内存的目的，又避免了对现有的MMU工作流程的更改，避免缺页错误的发生，保障IPC通信的稳定性和 安全性。
基于第一方面，在可能的实施例中，处理器核还用于，在所述客户端进程需要调用服务端进程的服务时，配置所述共享内存空间中的一部分内存空间给所述客户端进程，以保存所述待传递数据。
实施本申请实施例，在caller需要调用callee服务时，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的一部分内存空间给caller保存待传递数据(msg)，即操作系统在共享内存中向caller分配保存代传递数据(msg)的内存段，该内存段中msg的虚拟地址与物理地址的映射关系与MMU管理的该页表中记录的映射关系是一致的，所以，后续IPC通信中，通过IPC引擎将msg VA从caller传递到callee后，callee可以根据该VA访问该页表获得该数据，从而，既达到了caller和callee共享内存的目的，又避免了对现有的MMU工作流程的更改，避免缺页错误的发生，保障IPC通信的稳定性和安全性。
基于第一方面，在可能的实施例中，在运行所述客户端进程前，所述处理器核还用于向所述IPC引擎硬件发送所述服务端进程的注册信息，所述注册信息包括所述标识；所述IPC引擎硬件还用于：接收所述注册信息；响应于所述注册信息在所述IPC引擎硬件中保存所述标识和所述服务端进程的入口地址；所述IPC引擎硬件具体用于：根据所述标识，找到所述入口地址；将所述入口地址设置到所述处理器核中的程序计数器(PC)；所述处理器核还用于，根据设置在所述PC中的所述入口地址运行所述服务端进程。
其中，IPC引擎硬件可包括callee寄存器集，callee寄存器集包括一组寄存器的集合，用于记录callee的上下文信息的指示信息。callee寄存器集具体用于记录多个callee的入口地址(callee entry address)，每个callee entry address对应一个callee的上下文信息。在一实施例中，callee entry address包括一个callee的服务函数的地址指针，该服务函数可以为回调函数(Callback函数)。IPC引擎可将CPU中的程序计数器(Program Counter，PC)设置到该callee entry address上，这样CPU就开始执行callee进程上下文，运行callee执行相对应的服务。
进一步的，callee寄存器集进一步包括首地址寄存器和计数寄存器，该首地址寄存器用于保存callee list的首地址，具体的，可以是callee list中的第一条callee entry address。计数寄存器用于记录callee入口地址的数目(entry list size)，具体的，callee list中每增加一个列表条目(即一条callee entry address)，计数寄存器记录的数目就加1。这样，通过callee寄存器集可根据多个callee的注册情况记录多个callee的入口地址(callee entry address)到callee list。在具体实现中，可以配置callee list的每个列表条目对应一个索引标识(ID)。该索引ID可以是callee的进程ID(即callee ID)，或者该索引ID可以与进程ID一一映射，索引ID可在callee向IPC引擎的注册后确定。这样，可以方便客户端进程(caller)与一个或多个callee进行IPC。
可以看到，通过本申请书实施例的IPC引擎可实现用户态内的上下文信息保存、上下文切换、或数据传递等，这些过程内核并不感知(即IPC过程可以不需要内核参与)，避免现有IPC机制(例如binder机制)中用户态和内核态频繁切换的弊端，将进程的IPC过程从内核中脱离，从而释放出大量CPU的软件执行时间，从而极大降低IPC过程的整体时延。
基于第一方面，在可能的实施例中，所述IPC引擎硬件还用于，在接收所述调用指令之后，查询所述处理器核中的状态寄存器以获得所述所述客户端进程的调用堆栈地址，并在所述IPC引擎硬件中保存所述客户端进程的调用堆栈地址；所述IPC引擎硬件具体用于，根据所述第二处理器指令调出所述调用堆栈地址，并指示所述处理器核根据所述调用堆栈地址恢复运行所述客户端进程。
具体的，IPC引擎硬件可包括链路寄存器，链路寄存器用于保存当前caller的入口地址，所述caller的入口地址对应于caller的上下文信息。具体的，链路寄存器可保存当前caller的调用堆栈地址，以记录当前触发者的调用行为，该调用堆栈地址与caller的上下文信息相关联。caller发起调用指令(ipccall)后，IPC引擎的IPC逻辑电路查询CPU中的状态寄存器，通过查询状态寄存器中最新保存caller状态就能够知道是哪个caller发起该调用，从而可保存该caller的调用堆栈地址到链路寄存器。当callee完成服务的执行后，链路寄存器可弹出当前caller的记录，实现进程切换(即CPU从callee的上下文切换为caller的上下文)，以恢复该caller的进程。通过本申请实施例提供的callee寄存器集和链路寄存器可以在硬件实现进程的上下文切换过程，从而释放出CPU的软件执行时间，降低IPC过程的时延。
基于第一方面，在可能的实施例中，所述IPC引擎硬件具体用于,检查所述客户端进程与所述服务端是否符合进程间通信的要求,在所述客户端进程与所述服务端符合进程间通信的要求时，根据所述标识指示所述处理器核运行所述服务端进程。执行本实施例使得本申请提供的IPC引擎硬件更加安全和可靠。
举例来说，IPC引擎可以通过IPC逻辑电路进行如下至少一种条件检查：
1)检查caller和callee是否处于不同的执行等级。
2)检查caller和callee是否在同一处理器核(core)，IPC逻辑电路可根据进程是否在同一core决定是否需要进行进程上下文信息的迁移。
3)检查caller的安全权限，以确定caller是否有权限调用callee的服务。
4)检查调用指令携带的相关参数是否满足长度要求。
基于第一方面，在可能的实施例中，所述调用指令和所述返回指令均为用户态指令。从而满足了caller的服务调用和callee的回调，实现了进程在用户态层面的交互，避免现有IPC机制(例如binder机制)中用户态和内核态频繁切换的弊端，实现软件上不切换至内核态，硬件上IPC引擎和CPU并行工作。
基于第一方面，在可能的实施例中，当caller需要向IPC引擎发起ipccall，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的一部分内存空间给caller保存待传递数据(msg)，并将该数据的虚拟地址(VA)指示给caller，并置访问权限为caller可读写，其余进程/线程不可读写。ipccall指令被执行时，权限检查通过后，IPC引擎根据callee entry的信息将该部分共享内存设置为callee可读，其他进程/线程不可读写。
第二方面，本申请实施例提供了一种用于进程间通信IPC的方法，本实施例的方法是在前面第一方面描述的系统中执行的方法。该方法包括：处理器核在IPC引擎硬件初始化时，将存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保 存进程间通信所需的待传递数据；根据所述共享内存空间的起始地址和长度建立页表，所述页表包含所述共享内存空间的虚拟地址到物理地址的映射关系；所述处理器核运行客户端进程，在所述客户端进程需要调用服务端进程的服务时，向IPC引擎硬件发送第一处理器指令，所述第一处理器指令是所述客户端进程对所述服务的调用指令，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；所述待传递数据的物理地址位于所述共享内存空间；所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程，并将所述待传递数据的虚拟地址发送给所述服务端进程；所述处理器核运行所述服务端进程，通过所述服务端进程根据所述待传递数据的虚拟地址查询所述页表获得所述待传递数据来执行所述服务；所述处理器核向所述IPC引擎硬件发送第二处理器指令，所述第二处理器指令是所述服务端进程的返回指令；所述IPC引擎硬件根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程。
基于第二方面，在可能的实施例中，所述处理器核在所述客户端进程需要调用服务端进程的服务时，配置所述共享内存空间中的一部分内存空间给所述客户端进程，以保存所述待传递数据。
基于第二方面，在可能的实施例中，在所述处理器核运行所述客户端进程前，所述方法还包括：所述处理器核向所述IPC引擎硬件发送所述服务端进程的注册信息，所述注册信息包括所述标识；所述IPC引擎硬件接收所述注册信息；响应于所述注册信息在所述IPC引擎硬件中保存所述标识和所述服务端进程的入口地址；相应的，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程，包括：所述IPC引擎根据所述标识，找到所述入口地址；将所述入口地址设置到所述处理器核中的程序计数器(PC)；所述处理器核根据设置在所述PC中的所述入口地址运行所述服务端进程。
基于第二方面，在可能的实施例中，所述处理器核向IPC引擎硬件发送第一处理器指令之后，所述方法还包括：所述IPC引擎硬件查询所述处理器核中的状态寄存器以获得所述所述客户端进程的调用堆栈地址，并在所述IPC引擎硬件中保存所述客户端进程的调用堆栈地址；相应的，所述IPC引擎硬件根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程，包括：所述IPC引擎硬件根据所述第二处理器指令调出所述调用堆栈地址，并指示所述处理器核根据所述调用堆栈地址恢复运行所述客户端进程。
基于第二方面，在可能的实施例中，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程之前，所述方法还包括：所述IPC引擎硬件检查所述客户端进程与所述服务端是否符合进程间通信的要求；相应的，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程具体包括：在所述客户端进程与所述服务端符合进程间通信的要求时，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程。
基于第二方面，在可能的实施例中，所述调用指令和所述返回指令均为用户态指令。
第三方面，本申请提供一种进程间通信IPC的方法，该方法应用于物理实体形态的IPC引擎(即IPC引擎硬件)；在所述IPC引擎硬件初始化时，所述处理器核将所述存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保存进程间通信所需的待传递数据；根据所述共享内存空间的起始地址和长度建立页表，所述页表包含所述共享内存空间的虚拟地址到物理地址的映射关系；
方法包括：所述IPC引擎接收来自客户端进程的调用指令；所述调用指令用于请求服务端进程的服务，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；所述IPC引擎根据所述服务端进程的标识激活所述服务端进程，以使所述所述服务端进程根据所述待传递数据的虚拟地址查询所述页表获得所述待传递数据来执行所述服务；所述待传递数据的物理地址位于所述共享内存空间所述IPC引擎接收来自所述服务端进程的返回指令，所述返回指令包括执行结果；其中，所述调用指令和所述返回指令均为用户态的处理器指令；所述IPC引擎根据所述返回指令恢复所述客户端进程。
基于第三方面，在可能的实施例中，在所述客户端进程需要调用服务端进程的服务时，所述处理器核配置所述共享内存空间中的一部分内存空间给所述客户端进程，以保存所述待传递数据。
基于第三方面，在可能的实施例中，所述待传递数据的长度大于预设阈值。
基于第三方面，在可能的实施例中，所述IPC引擎接收来自客户端进程的调用指令之前，所述方法还包括：所述IPC引擎接受所述服务端进程的注册；所述IPC引擎根据所述服务端进程的注册，记录所述服务端进程的标识和所述服务端进程的入口地址。
所述IPC引擎根据所述服务端进程的标识激活所述服务端进程，包括：所述IPC引擎根据所述服务端进程的标识，找到所述服务端进程的入口地址；所述IPC引擎根据所述服务端进程的入口地址运行所述所述服务端进程。
基于第三方面，在可能的实施例中，所述IPC引擎接收来自客户端进程的调用指令之后，还包括：所述IPC引擎记录所述客户端进程的入口地址；相应的，所述IPC引擎根据所述返回指令恢复所述客户端进程，包括：所述IPC引擎根据所述客户端进程的入口地址，将所述服务端进程的运行切换成所述客户端进程的运行。
基于第三方面，在可能的实施例中，所述IPC引擎根据所述服务端进程的标识运行所述服务端进程之前，还包括：所述IPC引擎检查所述客户端进程与所述服务端是否符合进程间通信的要求；相应的，所述IPC引擎根据所述服务端进程的标识激活所述服务端进程，包括：在所述客户端进程与所述服务端符合进程间通信的要求的情况下，所述IPC引擎根据所述服务端进程的标识激活所述服务端进程。
第四方面，本申请实施例还提供IPC引擎硬件，用于执行第三方面描述方法，或者可实现第二方面描述的方法中的IPC引擎硬件的功能，IPC引擎硬件包括IPC逻辑电路(或称IPC logic)、callee寄存器集、链路寄存器(或称link reg)、消息寄存器集，IPC引擎可以部署在CPU core，也可以独立部署。IPC引擎硬件可以是一种协处理器或者独立的处理芯片，一些实施例中，该IPC引擎硬件可以集成在处理器中，IPC引擎硬件与CPU core并行运行。又一些实施例中，该IPC引擎硬件可以独立于处理器，通过通信线路/接口进行通信。
第五方面，本申请提供一种计算机存储介质，所述计算机存储介质用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现第二方面或第三方面任意一项提供的方法。
第六方面，本申请提供一种计算机程序产品，所述计算机程序产品用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现第二方面或第三方面任意一项提供 的方法。
附图说明
图1是现有的Binder机制的场景示意图；
图2是本申请实施例提供的一种基于CS模式的客户端进程和服务端进程进行通信的可能的应用场景示意图；
图3是本申请实施例提供的又一种基于CS模式的客户端进程和服务端进程进行通信的可能的应用场景示意图；
图4A是本申请实施例中计算设备的一种可能的系统结构框图；
图4B是本申请实施例提供的一种物理硬件系统的示例图；
图4C是本申请实施例提供的一种计算设备的结构示意图；
图5A是本申请实施例提供的一种IPC引擎的一种可能的硬件架构；
图5B是本申请实施例提供的IPC引擎的一些应用场景示例图；
图5C是本申请实施例提供的IPC引擎的又一应用场景示例图；
图6是本申请实施例提供的一种进程间通信的方法流程示意图；
图7是本申请实施例提供的又一种进程间通信的方法流程示意图；
图8是本申请实施例提供的一种共享内存方案的场景示意图；
图9是本申请实施例提供的一种应用本申请方案的IPC通信场景示意图。
具体实施方式
本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应当理解，在本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
本申请提供了一种新的IPC机制，通过该IPC机制能够显著降低IPC过程的时延以及提升数据传递效率。为了更好理解本申请的方案，下面首先描述本申请实施例涉及的客户端-服务端(client-server，CS)模式。本文中，可以把服务(service)的请求方称为客户端(client)，服务的实现方称之服务端(server)，客户端的进程可简称为客户端进程，客户端进程是访问服务的进程，本文中也可称为发送进程(caller)。服务端的进程可简称为服务端进程。服务端进程是提供服务的进程，本文中也可称为接收进程(callee)。
参见图2和图3，图2和图3示例性描述了本申请实施例提供的基于CS模式的客户端进程和服务端进程进行通信的可能的应用场景。在一些可能的实施例中，这两个进程(客户端进程和服务端进程)可以是位于同一个计算设备内，即IPC体现的是同一个计算设备内的两个进程之间进行通信，这里的计算设备可以是终端，也可以是服务器。一种示例中，如图2所示，这两个进程可以运行于计算设备的同一处理器核，例如CPU core。又一种示例中，在计算设备具有多个CPU core的情况下，这两个进程可以运行于计算设备的不同CPU core(如图示的CPU core1和CPU core2)。又一些可能的实施例中，这两个进程还可以是位于不同的计算设备，即IPC体现的是两个不同计算设备(计算设备1和计算设备2)之间的进程间的通信，其中，计算设备1和计算设备2可以均是终端，也可以是均是服务器，还可以是一个设备为终端而另一个设备为服务器。
以两个进程位于同一计算设备为例，该计算的操作系统类型可以是Android系统(安卓系统)，下述相关实施例的说明中，是以将本申请的进程间通信方法应用于Android系统为例进行说明。
本申请实施例中，计算设备的系统架构可以采用分层架构、事件驱动架构、微核架构、微服务架构、或云架构等进行设计。下面以分层架构的安卓(Android)系统为例，示例性说明计算设备的一种系统架构。参见图4A，图4A是本申请实施例中计算设备的一种可能的系统结构框图。该系统架构包括位于底层的物理硬件和运行于物理硬件上的软件架构，物理硬件层提供计算设备所需的各种计算资源(例如CPU)、存储资源(例如内存、磁盘等)、通信资源(例如收发器)等等。软件架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。
在一种可能实现中，将Android系统的软件架构从下往上分为：内核层(kerne)、硬件抽象层(HAL)、系统服务层、应用程序框架层和应用程序层。其中：内核层用于提供Linux内核和各类硬件设备的驱动。硬件抽象层用于封装内核层硬件驱动，提供可供系统服务层调用的统一硬件接口。系统服务层用于提供系统服务(service)，并且提供可供应用程序框架层调用的接口。应用程序框架层可以理解为Android SDK，用于提供四大组件、绘制等平时开发中用到的基础部件，开发者可以调用应用程序框架层的接口。应用程序层用于提供面向用户的应用程序(APP)。
需要说明的是，本申请实施例中计算设备采用的内核层可以是宏内核(Monolithic kernel)，也可以是微内核(Micro kernel)。其中，宏内核例如linux内核，宏内核除了提供最基本的进程、线程管理、内存管理外，还提供文件系统、驱动、网络协议等等。而对于微内核(例如SEL4、QNX、Fuchsia、LK etc)架构来说，内核中提供最基本的调度和内存管理。而驱动、文件系统等都是用户态的守护进程去实现的，带来更好的可扩展性、安全性和容错能力，被应用于越来越丰富的产品(例如移动终端、车机、飞行器设备等)中。
本申请实施例中，将IPC的处理逻辑设置到物理硬件层而不是内核层，设计专用的硬件形态的IPC引擎(IPC Engine)，本文中还可以将该IPC引擎称为IPC引擎硬件，IPC引擎作为进程交互的核心，可与内核并行处理，内核可对IPC引擎进行初始化、配置、控制、服务进程注册、异常中断处理等等。IPC过程涉及的服务调用(函数调用)、上下文切换、 数据交换(数据访问权传递)等由该IPC引擎以硬件方式完成，在IPC引擎内部进行数据或数据地址的传递，从避免了软件方式进行内核态及用户进程堆栈的上下文切换及数据拷贝等，从而释放出大量CPU的软件执行时间，降低整体时延。
IPC引擎可以脱离CPU的软件执行周期而并行运行。在一种IPC引擎实现中，可以在CPU Core所在芯片中增加IPC Engine的硬件专用逻辑作为协处理器，即将CPU Core和IPC Engine集成在同一个芯片内；在又一种IPC引擎实现中，IPC引擎可以是独立于CPU Core的处理芯片。
另外，为了实现IPC引擎与进程间的交互，向进程提供了处理器指令的方式来使用该IPC引擎，该处理器指令例如“ipccall指令”和“ipcret指令”。用户空间的客户端进程(caller)可以通过ipccall指令调用服务端进程(callee)的服务，服务端进程可以通过ipcret指令返回，以恢复客户端进程。以上两个指令执行的前提是IPC引擎完成初始化(例如包括IPC引擎的初始化配置、内存分配等)，初始化过程可由内核态驱动完成。
通过本申请的设计，Android中应用程序框架层以SDK的形式开放给开发者使用，系统服务层中的核心服务随系统启动而运行，通过应用程序框架层提供的管理器(Manager)实时为应用程序提供服务调用。系统服务层中每一个服务运行在自己独立的进程空间中，应用程序可通过IPC引擎调用系统服务层中的服务(service)。因此，可以硬件实现上下文切换、数据交换等过程，CPU借助IPC软件通信方式通过IPC引擎实现了软硬协同工作，释放出CPU的软件执行时间。这样，表现在用户进程的层面上，caller和callee实现了在用户态直接IPC的通信，从而避免了现有方案中内核态和用户态之间的切换所带来的时延，进程间的数据交互可以只传递数据地址(数据访问权)，从而减少甚至消除了数据拷贝的发生，大大提升了数据传输效率，进一步降低IPC过程的时延。
本申请实施例还提供的一种物理硬件系统，包括：中央处理单元(CPU)和IPC引擎硬件，本文中IPC引擎硬件可简称为IPC引擎，在具体实现上IPC引擎硬件可以是一种逻辑电路或者独立的逻辑计算芯片。其中：该CPU包括CPU核(CPU core)，一些实施例中，该IPC引擎可以集成在该CPU中，IPC引擎与CPU core并行运行。又一些实施例中，该IPC引擎可以独立于所述处理器核。
参见图4B，图4B是本申请实施例还提供的一种物理硬件系统的示例图，该物理硬件系统包括CPU core11、IPC引擎12和DDR内存13。其中，CPU core11、IPC引擎12和DDR内存13中的部分或者全部可以集成在一起，或者通过通用的通信接口相连接，或者通过总线相连接。其中：CPU core11可用于运行进程(客户端进程caller或服务器进程callee)，IPC引擎12可用于实现进程间的通信，DDR内存13可用于提供进程运行所必要的数据和上下文信息。具体的：CPU core可预先向IPC引擎进行所述服务端进程的注册，IPC引擎根据所述注册保存所述服务端进程的标识和所述服务端进程的入口地址。CPU core可用于，在客户端进程需要调用服务端进程的服务时，向所述IPC引擎发送第一处理器指令，所述第一处理器指令包括所述客户端进程对所述服务的调用指令(如本申请任意实施例描述的ipccall)，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；该待传递数据的虚拟地址可以是该待传递数据在DDR内存中的位置对应的虚拟地址。
IPC引擎可用于，保存客户端进程的入口地址；以及根据服务端进程的标识(ID)，找 到所述服务端进程的入口地址，进而指示CPU core运行所述服务端进程，从而实现了进程的上下文切换。此外，IPC引擎还可以建立待传递数据的地址和服务端进程在内存空间的地址之间映射，并将该映射传递给服务端进程，实现了数据访问权(而非数据本身)的传递。
CPU core还用于，运行所述服务端进程根据所述待传递数据来执行所述服务；CPU core还用于，向所述IPC引擎发送第二处理器指令，第二处理器指令包括服务端进程的返回指令(如本申请任意实施例描述的ipcret)。其中，第一处理器指令和第二处理器指令均为用户态的处理器指令。IPC引擎还用于，找到客户端进程的入口地址并指示所述所述处理器核运行所述客户端进程，从而实现了客户端进程的恢复。
可以看到，实施本申请实施例中可以在IPC引擎硬件上实现进程的上下文保存、上下文切换、数据交换等过程，在caller真正发起IPC后，IPC过程可以不需要内核参与，实现软件上不切换至内核态，硬件上IPC引擎和CPU core并行工作，CPU借助IPC软件通信方式通过IPC引擎实现了软硬协同工作，从而释放出CPU core的软件执行时间，为了配合硬件形态的IPC引擎与进程间的交互，还提供用户态的处理器指令(第一处理器指令和第二处理器指令，从而满足了caller的服务调用和callee的回调，实现了进程在用户态层面的交互，并保证了IPC过程的可实现性。这样，表现在用户进程的层面上，caller和callee实现了在用户态直接IPC的通信，从而避免了现有IPC机制(例如binder机制)中用户态和内核态频繁切换所带来的时延。进程间的数据交互可以只传递数据地址的映射(数据访问权)，从而减少甚至消除了数据拷贝的发生，大大提升了数据传输效率，进一步降低IPC过程的时延。
进一步地，参见图4C，图4C示例性地示出了一种计算设备30的结构示意图。该计算设备30可以是终端或者服务器。应该理解的是，本申请实施例示意的结构并不构成对计算设备30的具体限定。如图4C所示，计算设备30可包括：芯片310、存储器315、用户接口314。这些部件可在一个或多个通信总线上通信。
芯片310可集成包括：一个或多个处理器311、IPC引擎硬件312以及电源管理模块313。处理器311可以执行运算，产生操作控制信号，完成取指令和执行指令的控制，运行进程(如客户端进程caller或者服务端进程collee)等等。集成于芯片310中的电源管理模块313主要用于为芯片310以及计算设备30的其他部件提供稳定的、高精确度的电压。集成于芯片310中的IPC引擎硬件312可以是本申请任意实施例描述的IPC引擎，在IPC通信中实现进程的上下文保存、上下文切换、数据交换等过程。
IPC引擎硬件312可以是一种协处理器或者独立的处理芯片，一些实施例中，该IPC引擎硬件312可以集成在该处理器311中，IPC引擎硬件312与CPU core并行运行。又一些实施例中，该IPC引擎硬件312可以独立于处理器311，通过通信线路/接口进行通信。IPC引擎硬件312的具体功能实现可参考本申请任意实施例中关于IPC引擎的描述。
处理器311具体可以包括一个或多个不同能力的处理单元，例如：处理器311可以包括之前实施例所述的中央处理器(CPU，central processing unit)，应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信 号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中每个处理单元可以包括一个或多个核心(core)。
在一些实施例中，处理器311可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pul se code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
存储器315可与处理器311通过总线连接，也可以与处理器311耦合在一起，用于存储各种数据、软件程序和/或多组指令。具体实现中，存储器315可包括DDR内存，用于存储进程运行所必要的数据和上下文信息。存储器315还可以包括高速随机存取的存储器(例如高速缓冲存储器)，存储器315还可以包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。
用户接口314可用于连接计算设备30中的外围设备，例如各种输入/输出设备(I/O设备，传感器，显示屏等，本申请实施例不做现限制。
下面描述本申请实施例中IPC引擎的一种可能的硬件架构。参见图5A，该硬件架构可包括IPC逻辑电路(或称IPC logic)、callee寄存器集(也可称为第二寄存器集)、链路寄存器(或称link reg)、消息寄存器集(也可称为第一寄存器集)，IPC引擎可以部署在CPU core，也可以独立部署。
IPC逻辑电路作为IPC引擎的控制中心，可响应两个用户态的处理器指令ipccall、ipcret，所述ipccall、ipcret是进程可在用户态进行调用的指令；进行IPC流程的控制处理，完成针对callee和caller的各项条件检查等等。
callee寄存器集包括一组寄存器的集合，用于记录callee的上下文信息的指示信息。其中寄存器例如可以是32位或64位的寄存器，本申请对寄存器的位宽不做限定。具体的，callee寄存器集具体用于记录多个callee的入口地址(callee entry address)，每个callee entry address对应一个callee的上下文信息。所以，也可以称该callee entry address为“callee的上下文信息的指示信息”。
在一实施例中，callee entry address可以表示一个callee进程在全局DDR(例如图4B中的DDR内存13)中的上下文所在的地址。示例性地，callee entry address的具体内容可以是但不限于：页表指针(page table pointer)、地址指针、虚拟地址、或物理地址中至少一个。
在一实施例中，callee entry address包括一个callee的服务函数的地址指针，该服务函数可以为回调函数(Callback函数)，也就是说，callee的地址指针指向了callee注册的回调函数(Callback函数)地址，回调函数用于callee执行对应的服务(service)。回调函数属于一种handler，是一个通过函数指针调用的函数，通过回调函数来实现函数 之间的调用。如果把函数的指针(地址)作为参数传递给另一个函数，当这个指针被用为调用它所指向的函数时，即称这个函数是一个回调函数。IPC引擎可将CPU中的程序计数器(Program Counter，PC)设置到该callee entry address上，这样CPU就开始执行callee进程上下文，运行callee执行相对应的服务。
每次通过callee寄存器集可以实现记录一个callee entry address，当callee寄存器集多次记录多个callee的callee entry address时，这些callee entry address即可形成一种列表，这个列表可称为callee列表(callee list)，这个列表可保存在内存中，以供索引。callee寄存器集可视为callee list的管理者，对外提供callee list的注册、编辑(增、删)、维护、访问、或查询等功能。
如图5A所示，在可能的实现中，callee寄存器集进一步包括首地址寄存器和计数寄存器，该首地址寄存器用于保存callee list的首地址，具体的，可以是callee list中的第一条callee entry address。计数寄存器用于记录callee入口地址的数目(entry list size)，具体的，callee list中每增加一个列表条目(即一条callee entry address)，计数寄存器记录的数目就加1。这样，通过callee寄存器集可根据多个callee的注册情况记录多个callee的入口地址(callee entry address)到callee list。
参见图5B，图5B中的(1)示出了向IPC引擎注册callee到callee list的场景示例图。在具体实现中，可以配置callee list的每个列表条目对应一个索引标识(ID)。该索引ID可以是callee的进程ID(即callee ID)，或者该索引ID可以与进程ID一一映射，索引ID可在callee向IPC引擎的注册后确定。这样，可以方便客户端进程(caller)与一个或多个callee进行IPC。
callee向IPC引擎的注册过程可通过系统调用完成，例如可利用kernel内核对应的设备驱动CPU core的用户接口，根据callee的上下文信息保存相关内容(例如地址指针)到IPC引擎的首地址寄存器中。
这样，在IPC过程中，IPC引擎就可以根据caller传入的ID找到callee entry address。如图5B中的(2)所示，caller向IPC引擎发起的调用指令(ipccall)中携带callee的标识(callee ID)，这样，IPC逻辑电路可以根据该callee ID查找callee list，从而索引到该callee的的入口地址(callee entry address)。IPC引擎还可将CPU中的程序计数器(Program Counter，PC)设置到该callee entry address，以使callee运行并提供相应的服务。程序计数器是寄存器，它保存当前正在执行的指令的地址(位置)。当每个指令被获取，程序计数器的存储地址加一。在每个指令被获取之后，程序计数器指向顺序中的下一个指令。所以，IPC引擎可将该callee entry address发给该PC进行记录，这样CPU就执行指令运行callee。
本申请实施例中，当IPC引擎部署在CPU core时，CPU core的用户接口可提供callee entry address的增加(add)、移除(remove)等系统调用，callee服务的注册和注销也可通过该接口实施。
链路寄存器用于保存当前caller的入口地址，所述caller的入口地址对应于caller的上下文信息。具体的，链路寄存器可保存当前caller的调用堆栈地址，以记录当前触发者的调用行为，该调用堆栈地址与caller的上下文信息相关联。caller发起调用指令 (ipccall)后，IPC引擎的IPC逻辑电路查询CPU中的状态寄存器，通过查询状态寄存器中最新保存caller状态就能够知道是哪个caller发起该调用，从而可保存该caller的调用堆栈地址到链路寄存器。当callee完成服务的执行后，链路寄存器可弹出当前caller的记录，实现进程切换(即CPU从callee的上下文切换为caller的上下文)，以恢复该caller的进程。通过本申请实施例提供的callee寄存器集和链路寄存器可以在硬件实现进程的上下文切换过程，从而释放出CPU的软件执行时间，降低IPC过程的时延。
消息寄存器集包括一组寄存器的集合，用于记录caller需要向callee传递的数据(msg)的地址。其中寄存器例如可以是32位或64位的寄存器，本申请对寄存器的位宽不做限定。消息寄存器集可用于建立及保存指示信息(例如指针)，该指示信息指示了IPC通信过程中需要传递的数据(msg)的虚拟地址(VA)到物理地址(PA)的映射关系，该映射关系可保存在内存中。
具体实施例中，消息寄存器集用于记录多个msg的入口地址(msg entry address)。在具体实现中，消息寄存器集可记录caller在调用指令中传入的数据的地址，或者数据本身(例如仅有若干字节的小型数据)。每个msg entry address指示了msg在DDR内存中的地址(可简称msg内存地址)，该msg entry address可包含以下至少一项：虚拟地址的基地址(VA base)、物理地址的基地址(PA base)、地址空间长度(length)。可以看到，消息寄存器集可以记录一个或多个caller的需要传递的数据的地址，从而方便caller与一个或多个callee进行IPC。需理解，后续实施例以内存为例作介绍，但不用于限定，可扩展到其他类型存储器。
一个caller通过调用指令(ipccall)传入的可以是一个或多个msg的地址。在一实施例中，传入的msg的地址可以是msg的虚拟地址(virtual address，VA)。每次通过消息寄存器集可以实现记录一个或多个msg entry address。当消息寄存器集多次记录msg entry address后，这些msg entry address即可形成一种列表，这个列表可称为msg列表(msg list)，这个列表可保存在内存中，以供索引。消息寄存器集可视为msg list的管理者，对外提供msg list的编辑(增、删)、维护、访问、或查询等功能。
本申请一些实施例中，为了避免IPC过程中待传递数据的拷贝(copy)，在IPC引擎中，可以不直接传递数据本身，而是通过传递数据的映射(内存映射)来间接实现数据的传递，而不需要拷贝数据。具体的，可在IPC引擎中增加msg地址空间的映射机制，预先在DDR全局内存中配置一部分的内存作为共享内存，该共享内存可供caller和callee共享访问。也就是说，caller和callee共享一段内存空间，该一段内存空间就是本文中所称的共享内存)，待传递数据msg的物理地址(PA)即为msg在所述一段内存空间中的位置。共享内存用于存储服务调用过程所需要传输的数据(msg)，以使msg只在caller和callee之间映射。
具体的，参见图8，本申请实施例在系统初始化(IPC引擎初始化)时，运行于处理器核的操作系统在物理内存中预留(或称配置)一部分内存作为caller和callee的共享内存，为了提高数据访问安全性，还可以初始化内存访问权限。同时可以把对这部分共享内存访问的逻辑统一到现有的内存管理单元(memory management unit，MMU)的访问逻辑中，以避免对现有MMU执行流程的改动，避免产生缺页错误。也就是说，本申请实施例 中，共享内存是在IPC引擎初始化时固定预留分配的，这部分共享内存不在内核(例如kernel)的page管理页表中。这部分共享内存可由IPC引擎直接访问。该共享内存可用于保存IPC通信过程中需要在进程间传递的数据。通过预留该共享内存，能够建立专用的页表(该页表包含虚拟地址和物理地址的映射关系)，保证待传递数据始终有对应的物理页，从而避免缺页错误。
共享内存分配后，在共享内存全局形成了虚拟地址(VA)到物理地址(Physical Address,PA)的映射关系，IPC通信涉及的各个msg保存在该共享内存中，从而形成了大量msg虚拟地址(VA)到物理地址(Physical Address,PA)的映射关系(例如映射表)，IPC引擎可以访问这样的映射表。在caller需要调用callee服务时，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的一部分内存空间给caller保存待传递数据(msg)，并将该数据的虚拟地址(VA)指示给caller，以便于caller发起调用指令ipccall。
后续当caller向IPC引擎发起调用指令时，IPC引擎的IPC逻辑电路可以通过查找映射表来实现对msg list的维护。
参见图5C，图5C示出了向IPC引擎根据caller的调用指令(ipccall)维护msg list的场景示例图。如图5C所示，在可能的实现中，消息寄存器集进一步包括msg寄存器和计数寄存器，msg寄存器示例性地也可以是首地址寄存器，用于保存msg list的首地址，具体的，可以是msg list中的第一条msg entry address。计数寄存器用于记录msg入口地址的数目，具体的，msg list中每增加一个列表条目(即一条msg entry address)，计数寄存器记录的数目就加1。这样，通过消息寄存器集可记录一个或多个msg entry address到callee list。其中，每个列表条目(即一条msg entry address)可具体表示为msg在共享内存中的物理地址(PA)。具体实现中，caller的ipccall中可携带msg VA(如图示的VA1)，IPC引擎的IPC逻辑电路可基于该msg VA查找共享内存对应的映射表，从而确定该msg VA对应的PA(如图示的PA1)，该PA即作为msg entry address，通过消息寄存器集记录该msg entry address到msg list。可以理解的，当caller传入多个msg VA时，通过消息寄存器集可将多个msg entry address记录到msg list。
在具体实现中，为了便于数据查找，可以配置msg list的每个列表条目(PA)对应一个虚拟地址(VA)。也就是形成msg VA到PA的映射关系。这样，后续只需传递msg VA到callee而不需要传递msg本身，避免数据复制的弊端，提高传输效率。
一些实施例中，IPC通信过程中，Callee可使用该VA查询IPC引擎维护的msg list实现数据的获得。查询过程例如包括：callee使用msg VA向IPC引擎请求对应的PA，IPC引擎的IPC逻辑电路基于映射关系找到VA中对应的PA，再发给callee。
又一些实施例中，共享内存分配后，在callee注册到IPC引擎时，callee还可以根据该共享内存的起始地址和长度(size)，建立本进程的页表并添加到MMU中，该页表从全局定义了该段共享内存的虚拟地址(VA)和物理地址(Physical Address,PA)之间的映射关系，callee可以根据VA访问该页表以直接获得VA对应的PA，即callee可使用VA直接访问共享内存中的数据(msg)，从而实现了将地址访问逻辑统一到MMU，避免对现有MMU流程作更改，从而进一步提高了方案的可行性。在该实施例中，IPC引擎维护的msg list可 用于数据正确性的校验，即建好msg list后，当该caller又发起该服务的调用时，IPC引擎通过msg list核查该VA对应的PA是否在共享内存中(即msg list中是否记录VA与位于共享内存的PA的映射关系)。
进一步地，为了实现数据访问的安全性和准确性，IPC引擎的IPC逻辑电路可以通过设置callee对IPC引擎维护的msg list的查询权限，来实现对msg的访问权限的控制。例如，当caller需要向IPC引擎发起ipccall，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的一部分内存空间给caller保存待传递数据(msg)，并将该数据的虚拟地址(VA)指示给caller，并置访问权限为caller可读写，其余进程/线程不可读写。对于caller调用服务时传入的callee ID对应的callee，IPC引擎可以在该callee的上下文信息中开启查找权限，即允许该callee ID对应的callee使用VA去查询IPC引擎维护的msg list，将该数据所在的内存设置为callee可读，其他进程/线程不可读写，从而实现对msg的访问。而对于其他callee，则默认查找权限是关闭的，所以其他callee无法查询该msg list，这样避免了其他callee非法访问数据，提高了数据访问的安全性和准确性。
此外，在IPC逻辑电路执行周期中，还可以禁止不同CPU core对IPC引擎上的资源同时进行访问，以抵抗可能的恶意攻击程序，提升IPC过程的安全性。
可以看到，通过共享内存可以让数据(msg)在caller和callee之间映射，IPC引擎维护msg VA到PA的映射关系，IPC引擎可以根据caller发起的ipccall设置msg的访问权，后续只需要将msg VA传递给callee即可。从而实现在不依赖内核、无数据拷贝的情况下间接完成数据的传递，且传递过程对外不可见。也可以理解为，本申请实施例中，当前caller的数据传递形式可以是数据的访问权(而非数据本身)的传递，该访问权从caller的调用链上获取，比如caller->callee，从而节省了传输资源，提升数据传递效率。
需要说明的是，本文中，所谓的“进程的上下文信息”，可视为与进程的状态相关的各种变量、数据及进程执行时的环境，包括与该进程相关的所有寄存器的变量、进程打开的文件、或内存信息等等。当发生进程调度时，进行进程切换就是进程的上下文切换，需要对上面提到的上下文信息进行切换，新调度的进程才能运行。例如，当需要从客户端进程切换到服务端进程时，需要保存客户端进程的所有状态，同时，加载服务端进程的状态。这样，服务结束时，就能根据客户端进程的上下文信息恢复被中断的客户端进程的状态。
可以看到，本申请实施例通过设计专用的硬件形态的IPC引擎，IPC引擎可以作为协处理器或者单独的执行单元，脱离CPU的软件执行周期而并行运行。IPC引擎中进一步提供了IPC逻辑电路和多个寄存器，以建立新的IPC机制。为了配合硬件形态的IPC引擎与进程间的交互，本申请实施例还设计了分别供caller和callee使用的用户态的处理器指令：ipccall和ipcret，以便于调用接口，从而满足了caller的服务调用和callee的回调，保证了IPC过程的可实现性。以上两个指令执行的前提是IPC引擎完成初始化，初始化过程可由内核态驱动完成，包括IPC引擎的初始化配置、内存分配等。
通过IPC引擎可实现用户态内的上下文信息保存、上下文切换、或数据传递等，这些过程内核并不感知(即IPC过程可以不需要内核参与)，避免现有IPC机制(例如binder机制)中用户态和内核态频繁切换的弊端，将进程的IPC过程从内核中脱离，从而释放出 大量CPU的软件执行时间，从而极大降低IPC过程的整体时延。
另外，本申请实施例中的IPC引擎对数据内存进行映射，仅需要将数据的虚拟地址传递给callee即可，而不需要传递数据本身，从而避免了对数据的拷贝(copy)，消减了数据拷贝的时延，并提升数据传输效率。
另外，实施本申请实施例的方案，还可实现在IPC引擎初始化后，操作系统分配共享内存，且callee发起注册后建立本进程的页表，由MMU管理。caller需要调用服务时，操作系统在共享内存中向caller分配保存代传递数据(msg)的内存段，该内存段中msg的虚拟地址与物理地址的映射关系与MMU管理的该页表中记录的映射关系是一致的，所以，后续IPC通信中，通过IPC引擎将msg VA从caller传递到callee后，callee可以根据该VA访问该页表获得该数据，从而，既达到了caller和callee共享内存的目的，又避免了对现有的MMU工作流程的更改，避免缺页错误的发生，保障IPC通信的稳定性和安全性。
需要理解，图5A中IPC引擎可以是以纯硬件实现，包括大量逻辑电路、算法电路或寄存器，还可包括各类接口或模拟电路等，本实施例不做限定。当IPC引擎是协处理器的时候，可以是以不执行软件的纯硬件实现，也可以部分以能够运行软件的协处理器的方式实现，即此时IPC引擎的功能通过运行必要软件来实现，此时图5A中对应的各个部件可以运行必要的软件模块来实现技术方案。此时的IPC引擎仍然是独立于CPU的一个硬件加速器，但是需要必要的软件来驱动其工作，本实施例对此不作具体展开。
对于下文描述的各方法实施例，为了方便起见，将其都表述为一系列的动作步骤的组合，但是本领域技术人员应该知悉，本申请技术方案的具体实现并不受所描述的一系列的动作步骤的顺序的限制。
基于上文描述的系统架构和IPC引擎，下面描述本申请实施例提供的一种进程间通信(IPC)的方法流程，参见图6，该方法从IPC引擎侧的角度进行描述，包括但不限于以下步骤：
S100.在IPC引擎硬件初始化时，运行于处理器核的操作系统将存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保存进程间通信所需的待传递数据。其中，该存储器可以是内存，例如DDR内存，如DDR SDRAM(Double Data Rate SDRAM，双倍速率SDRAM)。
本申请实施例在系统初始化(IPC引擎初始化)时，操作系统在物理内存中固定预留一部分内存作为caller和callee的共享内存，该共享内存可用于保存IPC通信过程中需要在进程间传递的数据。
在一些实施例中，在运行callee进程前，callee可以根据共享内存空间的起始地址和长度(size)建立页表，该页表由MMU管理，该页表包含所述共享内存空间的虚拟地址到物理地址的映射关系，以便于callee在后续IPC通信中基于VA查找页表获得代传递数据。
在又一些实施例中，在IPC引擎的寄存器中保存指示信息(指针)，该指示信息指示待传递数据的虚拟地址与所述待传递数据的物理地址的映射关系，以便于后续callee在后续IPC通信中基于VA向该IPC引擎查询获得代传递数据。
当caller需要向IPC引擎发起ipccall调用，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的内存段给caller保存待传递数据(msg)，并将该数据的虚拟地址(VA)指示给caller。该内存段中msg的虚拟地址与物理地址的映射关系与MMU管理的该页表中记录的映射关系是一致的。
上述实施例的相关实现内容可以参考前文的相关描述，这里不再赘述。
S101.IPC引擎接收来自客户端进程的调用指令，该调用指令可以是本文描述的ipccall，该调用指令用于请求服务端进程的服务，调用指令包括所述服务端进程的标识和待传递数据的地址。该地址可为虚拟地址。
本申请实施例中，服务端(Server)作为很多服务(Service)的拥有者，在它能向客户端(Client)提供服务之前，可以先通过服务端进程(callee)向IPC引擎注册自己的服务。一种实现中，当callee启动后，可以借助内核驱动的辅助来完成注册过程，其中所述内核可以是宏内核也可以是微内核，本申请不做限定。
服务端可以向IPC引擎注册一个或者多个服务，所述IPC引擎根据callee的注册，记录callee的标识(ID)和callee的入口地址(callee entry address)，所述callee的入口地址与callee的上下文信息对应。
由于在IPC引擎中已经预先注册了各种服务的信息，所以caller可以从IPC引擎获知取有哪些服务可供使用。客户端作为服务的使用者，当客户端需要使用一种或多种的callee的服务时，可通过客户端进程(caller)向IPC引擎申请一种或多种的服务。此时，客户端的caller可以在用户层使用调用指令(ipccall)来请求IPC引擎服务。
其中，调用请求中可包含需要调用服务的命令、callee的ID和参数msg的地址等信息。
S102.IPC引擎根据服务端进程的标识(ID)激活所述服务端进程，以使所述所述服务端进程根据所述待传递数据执行所述服务。
一方面，IPC引擎可根据所述服务端进程的标识，查找本地存储找到所述服务端进程的入口地址；然后，IPC引擎可将程序计数器(Program Counter，PC)设置到该callee入口地址上，开始执行callee进程上下文，从而使所述所述服务端进程运行。
另一方面，为了避免IPC过程中待传递数据的拷贝(copy)，在IPC引擎中，可以不直接传递数据本身，而是通过传递数据的映射(内存映射)到callee来间接实现数据的传递，而不需要拷贝数据。具体的，待传递数据的地址可以是msg VA，IPC引擎可根据共享内存机制建立msg VA到PA的映射关系，赋予callee对该映射关系的查询权限，并将VA传递到callee。或者callee可以根据该VA查询MMU中的页表获得该根据该VA对应的PA，从而实现对msg的访问。这样，后续callee就可以根据该VA查询IPC引擎实现对msg的访问，并根据msg执行客户端所需的服务。
S103.IPC引擎接收来自服务端进程的返回指令(ipcret)，所述返回指令包括执行结果。
本申请中的ipccall和ipcret都属于用户态的处理器指令，所以实现了IPC过程中caller和callee在用户态实现指令交互，避免陷入内核态。
S104.IPC引擎根据所述返回指令恢复所述客户端进程。
本申请实施例中，在IPC引擎接收到来自caller的ipccall后，也可以记录所述caller的入口地址。所述caller的入口地址与caller的上下文信息对应。这样，当IPC引擎收到callee的ipcret时，就可以根据所述caller的入口地址，将所述callee的运行切换成所述caller的运行，即实现进程的切换。具体的，当callee完成IPC的处理后，可执行ipcret。IPC引擎响应该ipcret，弹出当前caller记录,从而切换到caller上下文，恢复caller的状态。
可以看到，实施本申请实施例，可将用户态内的上下文信息保存、上下文切换和恢复、数据传递等从时间和空间上都转移到一个新的物理实体(即IPC引擎)实现。IPC引擎作为IPC的媒介，提供对应的用户态指令ipccall和ipcret，使得caller和callee在用户态就能完成上下文切换，而不用切换到内核态，从而满足了caller的服务调用和callee的回调，实现了进程在用户态层面的交互，IPC引擎可以和内核软件并行工作，极大降低IPC过程的整体时延。另外，在本申请实施例中可以通过IPC引擎进行数据访问权的传递，仅需要传递数据的虚拟地址给callee即可，而不需要传递数据本身，从而避免了对数据的拷贝(copy)，进一步消减了数据拷贝的时延，并提升数据传输效率。
另外，实施本申请实施例的方案，还可实现在IPC引擎初始化后，操作系统分配共享内存，且callee发起注册后建立本进程的页表，由MMU管理，caller需要调用服务时，操作系统在共享内存中向caller分配保存代传递数据(msg)的内存段，该内存段中msg的虚拟地址与物理地址的映射关系与MMU管理的该页表中记录的映射关系是一致的，所以，后续IPC通信中，通过IPC引擎将msg VA从caller传递到callee后，callee可以根据该VA访问该页表获得该数据，从而，既达到了caller和callee共享内存的目的，又避免了对现有的MMU工作流程的更改，避免缺页错误的发生，保障IPC通信的稳定性和安全性，提高产品的落地可行性。
基于上文描述的系统架构和IPC引擎，下面描述本申请实施例提供的又一种进程间通信(IPC)的方法流程，IPC引擎可以部署在CPU core中，借助CPU core的用户接口与外界进行交互，例如与进程交互。参见图7，该方法从多侧的角度进行方案的详细描述，包括但不限于以下步骤：
S200.在IPC引擎硬件初始化时，将存储器中的一部分内存空间配置为进程的共享内存空间，共享内存空间用于保存进程间通信所需的待传递数据。其中，该存储器可以是内存，例如DDR内存，如DDR SDRAM(Double Data Rate SDRAM，双倍速率SDRAM)。
本步骤的相关内存参考步骤S100的描述，这里不再赘述。
S201.callee启动后注册到IPC引擎。
示例性地，callee可通过内核注册到IPC引擎。当然，callee也可以通过其他方式实现注册到IPC引擎，例如对应具有微内核的系统，可以通过用户态的驱动实现注册到IPC引擎。本申请对注册方式不做具体限制。
本申请实施例中，服务端(Server)作为很多服务(Service)的拥有者，在它能通过IPC向客户端(Client)提供服务之前，得先通过服务端进程(callee)向IPC引擎注册自己的服务。服务端可以向IPC引擎注册一个或者多个服务。
一种实现中，当callee启动后，可以借助内核驱动的辅助来完成注册过程，其中所述内核可以是宏内核也可以是微内核，本申请不做限定。内核可以驱使IPC引擎保存该callee注册的信息，例如，注册过程可通过系统调用(例如callee list add指令)完成，IPC引擎根据该callee的ID，通过callee寄存器集形成一条callee entry address，并记录该callee的ID号，该ID号关联该callee entry address。可以理解的，对于同一服务端的不同进程，或者不同客户端的不同进程，均可以在IPC引擎中完成注册，每注册一个callee，就增加一条callee entry address，所有这些callee entry address可以形成一张列表(callee list)，该list指向全局DDR内存。所以一个callee entry address可以视为列表中的一个条目。而callee的ID号可以作为该条目的索引。
示例性地，callee的ID号可以是callee的进程号(processID，PID)。
S202.当caller需要callee的服务时，caller向IPC引擎发送服务的调用指令(ipccall)，该调用指令包括callee的ID和待传递数据的地址(例如记为msg地址信息)。该地址可以是虚拟地址。
本步骤中，由于在IPC引擎中已经预先注册了各种服务的信息，所以caller可以从IPC引擎获取有哪些服务可供使用。客户端作为服务的使用者，当客户端需要使用一种或多种的callee的服务时，需要向IPC引擎申请所述一种或多种的服务。此时，客户端的caller可以在用户层使用调用指令(ipccall)来请求IPC引擎服务，通过ipccall指令传入服务对应的callee的ID和相关参数，所述相关参数即包括待传递到callee的数据的地址(简称待传递数据的地址)，例如，所述待传递数据的地址为虚拟地址(即前文提及的msg VA)。
需要说明的是，本文中的ipccall可支持提供同步或异步的调用方式，本方法流程主要以同步调用方式为例进行方案的说明。
S203.IPC引擎对该caller与callee之间的IPC通信进行条件检查。
在本步骤中，响应于来自caller的ipccall，IPC引擎可以进行各种条件检查，以检验IPC通信的要求是否被满足。在一种可能实施例中，当条件检查通过时才继续执行后续步骤，如条件检查不通过，则可拒绝该ipccall。
举例来说，IPC引擎可以通过IPC逻辑电路进行如下至少一种条件检查：
1)检查caller和callee是否处于不同的执行等级。
2)检查caller和callee是否在同一处理器核(core)，IPC逻辑电路可根据进程是否在同一core决定是否需要进行进程上下文信息的迁移。
3)检查caller的安全权限，以确定caller是否有权限调用callee的服务。
4)检查调用指令携带的相关参数是否满足长度要求。
需要说明的是，本步骤属于可选的步骤。
S204.IPC引擎在链路寄存器(link reg)中记录caller上下文信息的指示信息，通过消息寄存器集中记录待传递数据的入口地址(msg entry address)。
本步骤中，IPC引擎可将caller上下文信息记录在link reg所指向的调用栈中，以待后续需要恢复caller时使用。另外，IPC引擎可根据caller传入的msg地址(例如msg CA)，通过消息寄存器集记录msg entry address到msg list。Caller在一次调用指令中传入的 msg地址可以是一个或多个，可以理解的，当caller需要与一个或多个callee进行IPC通信时，caller可分别传入对应不同callee的msg地址信息。
需要说明的是，在可能的实现中，本步骤也可以在步骤S203之前执行。
S205.IPC引擎根据callee的ID通过callee寄存器集找到callee entry address。
S206.IPC引擎根据callee entry address进行进程上下文切换，从而激活callee。
本申请实施例中，由于callee的ID和callee entry address具有明确的对应关系，IPC引擎可根据caller传入的ID在列表(callee list)中找到callee entry address，示例性的，该callee entry address可为一个callee的地址指针，callee的地址指针指向了callee注册的回调函数地址，该回调函数用于callee执行对应的服务(service)。那么，IPC引擎可将CPU中的程序计数器(Program Counter，PC)设置到该callee入口地址上，开始执行callee进程上下文，此时callee被激活以执行相应的服务。
S207.IPC引擎确定待传递数据的地址(虚拟地址)和内存地址之间的映射关系。
S208.IPC引擎将该待传递数据的地址(虚拟地址)传递给callee，将待传递数据的访问权转移给callee。
本申请一些实施例中，为了避免IPC过程中待传递数据的拷贝(copy)，在IPC引擎中，可以不直接传递数据本身，而是通过传递数据的映射(内存映射)来间接实现数据的传递，而不需要拷贝数据。如图8所示，一种具体实现方案是：在IPC引擎中增加msg地址空间的映射机制，让msg数据只在caller和callee之间映射。在IPC引擎初始化时，分配一部分的内存作为共享内存，建立确定msg的虚拟地址(VA)和内存地址(物理地址)之间的映射表，IPC引擎可以访问这样的映射表。当caller向IPC引擎发起ipccall时，IPC引擎可以根据传入的msg VA通过查找映射表来找到PA，并记录下该VA与该PA之间的映射关系来实现对msg list的维护。这样，一方面，IPC引擎只需传递msg VA到callee而不需要传递msg本身，避免数据复制的弊端，提高传输效率。另一方面，IPC引擎的IPC逻辑电路可以通过设置callee对IPC引擎维护的msg list的查询权限，来实现对msg的访问权限的控制。例如，当caller需要向IPC引擎发起ipccall，操作系统基于该共享内存对该caller进行内存分配，即分配该共享内存中的一部分内存空间给caller保存待传递数据(msg)，并将该数据的虚拟地址(VA)指示给caller，并置访问权限为caller可读写，其余进程/线程不可读写。ipccall指令被执行时，权限检查通过后，IPC引擎根据callee entry的信息将该部分共享内存设置为callee可读，其他进程/线程不可读写。具体的，对于caller调用服务时传入的callee ID对应的callee，IPC引擎可以在该callee的上下文信息中开启查找权限，即允许该callee ID对应的callee使用VA去查询IPC引擎维护的msg list，从而实现对msg的访问，或者callee可以根据该VA查询MMU中的页表获得该根据该VA对应的PA，从而实现对msg的访问。即实现数据访问权从caller到callee的传递。而对于其他callee，则默认查找权限是关闭的，所以其他callee无法查询该msg list，这样避免了其他callee非法访问数据，提高了数据访问的安全性和准确性。
本申请又一些实施例中，还可以根据待传递数据本身的长度，为不同长度的数据配置不同的传递方式，以提高数据传递的灵活性。
一种示例性方案可以是：配置小型数据(数据长度小于预设阈值，例如小于32字节)直接通过msg寄存器拷贝传递。配置大型数据(数据长度大于等于预设阈值，例如大于等于32字节)采用内存映射的方案进行传递，通过IPC引擎传递数据的访问权到callee来完成传递过程。
又一种示例性方案可以是：如果数据长度小于32字节，在进程上下文切换过程中直接通过msg寄存器拷贝传递；如果数据长度大于等于32字节并且小于IPC缓存大小(IPC BUF size，该大小可以自定义，如128字节)，可通过调度或者中断方式进行拷贝传递；如果数据长度大于IPC缓存大小(如大于128字节)，采用内存映射的方案进行传递，通过IPC引擎传递数据的访问权到callee来完成传递过程。
需要说明的是，本申请对预设阈值的具体大小不做限定，上述示例仅用于解释本申请方案而非限定。
还需要说明的是，上述S205-S208之间的步骤之间没有必然的先后顺序。
S209.callee获取待传递数据并执行caller所需的服务。
本步骤中，caller可以根据数据的访问权获得msg(例如使用VA去查询IPC引擎维护的msg list，从而实现对msg的访问)，并调用相关函数来完成具体的服务(service)。系统服务层中的服务可通过应用层序框架层提供的Manager实时为应用程序提供。服务内容例如可以是消息、通信、摄像、或窗口使用等等，本申请不做不限制。
S210.callee向IPC引擎发送返回指令(ipcret)，该返回指令可携带服务的执行结果。
S211.IPC引擎利用链路寄存器恢复caller的执行。
在本步骤中，当callee完成IPC的处理后，可执行ipcret。IPC引擎的IPC逻辑电路响应该ipcret，控制链路寄存器(link reg)弹出最后一个caller记录,从而切换到caller上下文，恢复caller的状态。
为了更好理解本申请实施例的具体方案，下面进一步以图9为例进行描述。图示中，caller和callee之间的指令交互用虚线表示，目的是说明caller和callee可以在用户层实现服务调用，它们之间并不是真正的直接交互，而是通过硬件层的IPC引擎作为中介进行交互，从而实现IPC通信方式。
在使用IPC引擎后的一次IPC通信过程如下：IPC的服务进程callee启动后通过内核驱动注册到IPC引擎，caller在用户层使用ipccall指令请求IPC引擎服务，向IPC引擎传入对应的callee ID和相关参数msg的地址。caller的上下文信息被记录在IPC引擎的链路寄存器所指向的调用栈中，待需要恢复caller状态时使用，msg被记录在msg寄存器所指向的连续内存中。IPC引擎根据caller传入的ID找到callee入口地址，并将CPU中的程序计数器(Program Counter，PC)设置到该callee入口地址上，CPU开始切换到callee的进程上下文。IPC引擎还将msg的访问权传递到callee。这样，callee可执行对应服务的方法。callee完成IPC处理后，发送ipcret指令到IPC引擎，IPC引擎控制链路寄存器弹出caller记录，从而恢复caller进程的执行。在上述IPC过程中，IPC引擎的事件通知可通过中断方式上报给内核(kernel)。例如当IPC引擎发生异常时可通过中断方式报告给kernel，又例如当IPC处理完成时也可将该事件通过中断方式报告给kernel。
需要说明的是，本方法实施例中没有详细描述的地方可参考前文相关内容的描述，例如图4A，图4B，图5A，图5B，图5C等实施例，为了说明书的简洁，这里不再赘述。
可以看到，本申请实施例将用户态内的上下文信息保存、上下文切换和恢复、数据传递等从时间和空间上都转移到一个新的物理实体(即IPC引擎)实现，内核驱动预先协助完成collee的注册、IPC引擎初始化、内存分配等，在caller真正发起IPC后，IPC过程可以不需要内核参与，避免现有IPC机制(例如binder机制)中用户态和内核态频繁切换的弊端，实现软件上不切换至内核态，硬件上IPC引擎和CPU并行工作，从而释放出大量CPU的软件执行时间，为了配合硬件形态的IPC引擎与进程间的交互，还提供给caller和callee使用的用户态的处理器指令：ipccall和ipcret，以便于调用接口，从而满足了caller的服务调用和callee的回调，实现了进程在用户态层面的交互，并保证了IPC过程的可实现性，极大降低IPC过程的整体时延。实施本申请实施例，通过android平台的应用测试表明，可以将IPC过程的时延降低到20cycle，相比现有技术而言实现了IPC时延显著降低。
另外，在本申请实施例中可以通过IPC引擎进行数据(例如小型数据)或数据访问权的传递。具体的，IPC引擎对待传递数据msg内存进行映射，实现数据访问权的传递而不需要传递数据本身，从而避免了对数据的拷贝(copy)，进一步消减了数据拷贝的时延，并提升数据传输效率。
另外，实施本申请实施例的方案，还可实现在IPC引擎初始化后，操作系统分配共享内存，且callee发起注册后建立本进程的页表，由MMU管理，caller需要调用服务时，操作系统在共享内存中向caller分配保存代传递数据(msg)的内存段，该内存段中msg的虚拟地址与物理地址的映射关系与MMU管理的该页表中记录的映射关系是一致的，所以，后续IPC通信中，通过IPC引擎将msg VA从caller传递到callee后，callee可以根据该VA访问该页表获得该数据，从而，既达到了caller和callee共享内存的目的，又避免了对现有的MMU工作流程的更改，避免缺页错误的发生，保障IPC通信的稳定性和安全性。
上述实施例中，对各个实施例的描述各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

Claims (12)

  1. 一种用于进程间通信IPC的硬件系统，其特征在于，包括：处理器核、IPC引擎硬件和存储器，其中：
    所述处理器核用于，在所述IPC引擎硬件初始化时，将所述存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保存进程间通信所需的待传递数据；根据所述共享内存空间的起始地址和长度建立页表，所述页表包含所述共享内存空间的虚拟地址到物理地址的映射关系；
    所述处理器核还用于，运行客户端进程，在所述客户端进程需要调用服务端进程的服务时，向所述IPC引擎硬件发送第一处理器指令，所述第一处理器指令是所述客户端进程对所述服务的调用指令，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；所述待传递数据的物理地址位于所述共享内存空间；
    所述IPC引擎硬件用于，根据所述标识指示所述处理器核运行所述服务端进程，并将所述待传递数据的虚拟地址发送给所述服务端进程；
    所述处理器核还用于，运行所述服务端进程，所述服务端进程根据所述待传递数据的虚拟地址查询所述页表获得所述待传递数据来执行所述服务；以及，向所述IPC引擎硬件发送第二处理器指令，所述第二处理器指令是所述服务端进程的返回指令；
    所述IPC引擎硬件还用于，根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程。
  2. 根据权利要求1所述的硬件系统，其特征在于，所述处理器核还用于，在所述客户端进程需要调用服务端进程的服务时，配置所述共享内存空间中的一部分内存空间给所述客户端进程，以保存所述待传递数据。
  3. 根据权利要求1或2所述的硬件系统，其特征在于，
    在运行所述客户端进程前，所述处理器核还用于向所述IPC引擎硬件发送所述服务端进程的注册信息，所述注册信息包括所述标识；
    所述IPC引擎硬件还用于：接收所述注册信息；响应于所述注册信息在所述IPC引擎硬件中保存所述标识和所述服务端进程的入口地址；
    所述IPC引擎硬件具体用于：根据所述标识，找到所述入口地址；将所述入口地址设置到所述处理器核中的程序计数器(PC)；
    所述处理器核还用于，根据设置在所述PC中的所述入口地址运行所述服务端进程。
  4. 根据权利要求1-3任一项所述的硬件系统，其特征在于，
    所述IPC引擎硬件还用于，在接收所述调用指令之后，查询所述处理器核中的状态寄存器以获得所述所述客户端进程的调用堆栈地址，并在所述IPC引擎硬件中保存所述客户端进程的调用堆栈地址；
    所述IPC引擎硬件具体用于，根据所述第二处理器指令调出所述调用堆栈地址，并指 示所述处理器核根据所述调用堆栈地址恢复运行所述客户端进程。
  5. 根据权利要求1-4任一项所述的硬件系统，其特征在于，
    所述IPC引擎硬件具体用于,检查所述客户端进程与所述服务端是否符合进程间通信的要求,在所述客户端进程与所述服务端符合进程间通信的要求时，根据所述标识指示所述处理器核运行所述服务端进程。
  6. 根据权利要求1-5任一项所述的硬件系统，其特征在于，
    所述调用指令和所述返回指令均为用户态指令。
  7. 一种用于进程间通信IPC的方法，其特征在于，包括：
    处理器核在IPC引擎硬件初始化时，将存储器中的一部分内存空间配置为进程的共享内存空间，所述共享内存空间用于保存进程间通信所需的待传递数据；根据所述共享内存空间的起始地址和长度建立页表，所述页表包含所述共享内存空间的虚拟地址到物理地址的映射关系；
    所述处理器核运行客户端进程，在所述客户端进程需要调用服务端进程的服务时，向IPC引擎硬件发送第一处理器指令，所述第一处理器指令是所述客户端进程对所述服务的调用指令，所述调用指令包括所述服务端进程的标识和待传递数据的虚拟地址；所述待传递数据的物理地址位于所述共享内存空间；
    所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程，并将所述待传递数据的虚拟地址发送给所述服务端进程；
    所述处理器核运行所述服务端进程，通过所述服务端进程根据所述待传递数据的虚拟地址查询所述页表获得所述待传递数据来执行所述服务；
    所述处理器核向所述IPC引擎硬件发送第二处理器指令，所述第二处理器指令是所述服务端进程的返回指令；
    所述IPC引擎硬件根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程。
  8. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    所述处理器核在所述客户端进程需要调用服务端进程的服务时，配置所述共享内存空间中的一部分内存空间给所述客户端进程，以保存所述待传递数据。
  9. 根据权利要求7或8所述的方法，其特征在于，在所述处理器核运行所述客户端进程前，所述方法还包括：
    所述处理器核向所述IPC引擎硬件发送所述服务端进程的注册信息，所述注册信息包括所述标识；
    所述IPC引擎硬件接收所述注册信息；响应于所述注册信息在所述IPC引擎硬件中保存所述标识和所述服务端进程的入口地址；
    相应的，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程，包括：
    所述IPC引擎根据所述标识，找到所述入口地址；将所述入口地址设置到所述处理器核中的程序计数器(PC)；
    所述处理器核根据设置在所述PC中的所述入口地址运行所述服务端进程。
  10. 根据权利要求7-9任一项所述的方法，其特征在于，所述处理器核向IPC引擎硬件发送第一处理器指令之后，所述方法还包括：
    所述IPC引擎硬件查询所述处理器核中的状态寄存器以获得所述所述客户端进程的调用堆栈地址，并在所述IPC引擎硬件中保存所述客户端进程的调用堆栈地址；
    相应的，所述IPC引擎硬件根据所述第二处理器指令，指示所述处理器核恢复运行所述客户端进程，包括：
    所述IPC引擎硬件根据所述第二处理器指令调出所述调用堆栈地址，并指示所述处理器核根据所述调用堆栈地址恢复运行所述客户端进程。
  11. 根据权利要求7-10任一项所述的方法，其特征在于，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程之前，所述方法还包括：
    所述IPC引擎硬件检查所述客户端进程与所述服务端是否符合进程间通信的要求；
    相应的，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程具体包括：
    在所述客户端进程与所述服务端符合进程间通信的要求时，所述IPC引擎硬件根据所述标识指示所述处理器核运行所述服务端进程。
  12. 根据权利要求7-11任一项所述的方法，其特征在于，
    所述调用指令和所述返回指令均为用户态指令。
PCT/CN2020/087917 2020-04-29 2020-04-29 一种进程间通信的方法及系统 WO2021217529A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080001704.4A CN113939805A (zh) 2020-04-29 2020-04-29 一种进程间通信的方法及系统
PCT/CN2020/087917 WO2021217529A1 (zh) 2020-04-29 2020-04-29 一种进程间通信的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/087917 WO2021217529A1 (zh) 2020-04-29 2020-04-29 一种进程间通信的方法及系统

Publications (1)

Publication Number Publication Date
WO2021217529A1 true WO2021217529A1 (zh) 2021-11-04

Family

ID=78331604

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/087917 WO2021217529A1 (zh) 2020-04-29 2020-04-29 一种进程间通信的方法及系统

Country Status (2)

Country Link
CN (1) CN113939805A (zh)
WO (1) WO2021217529A1 (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114356583A (zh) * 2022-01-13 2022-04-15 浪潮商用机器有限公司 一种基于linux操作系统的slub内存申请监测方法及系统
CN114461158A (zh) * 2021-12-29 2022-05-10 沈阳中科创达软件有限公司 一种应用投屏方法、装置、车载终端及可读存储介质
CN114564429A (zh) * 2022-02-11 2022-05-31 北京智芯微电子科技有限公司 轻量级智能计算紧耦合结构及其数据处理方法
CN114691051A (zh) * 2022-05-30 2022-07-01 恒生电子股份有限公司 数据处理方法以及装置
CN115442173A (zh) * 2022-06-07 2022-12-06 北京车和家信息技术有限公司 车辆报文转发、处理方法、装置、电子设备及存储介质
WO2023093675A1 (zh) * 2021-11-25 2023-06-01 北京字节跳动网络技术有限公司 一种双向通信方法、装置、设备及介质
WO2024007207A1 (en) * 2022-07-06 2024-01-11 Huawei Technologies Co., Ltd. Synchronization mechanism for inter process communication
CN117573419A (zh) * 2024-01-16 2024-02-20 上海芯联芯智能科技有限公司 一种页面异常处理方法及装置
CN117573386A (zh) * 2023-10-31 2024-02-20 华为技术有限公司 进程间通信方法及装置
CN117692416A (zh) * 2024-02-04 2024-03-12 苏州元脑智能科技有限公司 网络报文处理方法、装置、计算机设备和存储介质
CN118467064A (zh) * 2024-07-01 2024-08-09 北京壁仞科技开发有限公司 参数传递方法和电子设备

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115202891B (zh) * 2022-09-15 2022-11-15 北京科云时代信息技术有限公司 基于大数据的跨进程数据采集传输方法、系统及存储介质
CN118689664A (zh) * 2023-03-21 2024-09-24 华为技术有限公司 一种程序间通信方法以及计算机设备
CN116561039A (zh) * 2023-04-28 2023-08-08 京东方科技集团股份有限公司 设备交互方法、系统、设备和可读存储介质
CN116185670B (zh) * 2023-05-04 2023-07-18 南京砺算科技有限公司 内存间的数据交换方法、装置、电子设备及存储介质
CN117112029B (zh) * 2023-10-24 2024-03-12 上海芯联芯智能科技有限公司 一种指令执行方法及装置
CN117785231B (zh) * 2024-02-26 2024-06-04 深圳海星智驾科技有限公司 车载操作系统及车辆

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104572313A (zh) * 2013-10-22 2015-04-29 华为技术有限公司 一种进程间的通信方法及装置
CN109933441A (zh) * 2019-02-28 2019-06-25 上海交通大学 微内核进程间通讯方法和系统
CN109933443A (zh) * 2019-03-07 2019-06-25 腾讯科技（深圳）有限公司 进程间通信方法、装置、计算机设备及可读存储介质
US20200014741A1 (en) * 2018-07-05 2020-01-09 Samsung Electronics Co., Ltd. System and method for device audio

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104572313A (zh) * 2013-10-22 2015-04-29 华为技术有限公司 一种进程间的通信方法及装置
US20200014741A1 (en) * 2018-07-05 2020-01-09 Samsung Electronics Co., Ltd. System and method for device audio
CN109933441A (zh) * 2019-02-28 2019-06-25 上海交通大学 微内核进程间通讯方法和系统
CN109933443A (zh) * 2019-03-07 2019-06-25 腾讯科技（深圳）有限公司 进程间通信方法、装置、计算机设备及可读存储介质

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023093675A1 (zh) * 2021-11-25 2023-06-01 北京字节跳动网络技术有限公司 一种双向通信方法、装置、设备及介质
CN114461158B (zh) * 2021-12-29 2024-02-09 沈阳中科创达软件有限公司 一种应用投屏方法、装置、车载终端及可读存储介质
CN114461158A (zh) * 2021-12-29 2022-05-10 沈阳中科创达软件有限公司 一种应用投屏方法、装置、车载终端及可读存储介质
CN114356583A (zh) * 2022-01-13 2022-04-15 浪潮商用机器有限公司 一种基于linux操作系统的slub内存申请监测方法及系统
CN114564429A (zh) * 2022-02-11 2022-05-31 北京智芯微电子科技有限公司 轻量级智能计算紧耦合结构及其数据处理方法
CN114691051A (zh) * 2022-05-30 2022-07-01 恒生电子股份有限公司 数据处理方法以及装置
CN115442173A (zh) * 2022-06-07 2022-12-06 北京车和家信息技术有限公司 车辆报文转发、处理方法、装置、电子设备及存储介质
CN115442173B (zh) * 2022-06-07 2024-02-06 北京车和家信息技术有限公司 车辆报文转发、处理方法、装置、电子设备及存储介质
WO2024007207A1 (en) * 2022-07-06 2024-01-11 Huawei Technologies Co., Ltd. Synchronization mechanism for inter process communication
CN117573386A (zh) * 2023-10-31 2024-02-20 华为技术有限公司 进程间通信方法及装置
CN117573419A (zh) * 2024-01-16 2024-02-20 上海芯联芯智能科技有限公司 一种页面异常处理方法及装置
CN117573419B (zh) * 2024-01-16 2024-04-26 上海芯联芯智能科技有限公司 一种页面异常处理方法及装置
CN117692416A (zh) * 2024-02-04 2024-03-12 苏州元脑智能科技有限公司 网络报文处理方法、装置、计算机设备和存储介质
CN117692416B (zh) * 2024-02-04 2024-05-03 苏州元脑智能科技有限公司 网络报文处理方法、装置、计算机设备和存储介质
CN118467064A (zh) * 2024-07-01 2024-08-09 北京壁仞科技开发有限公司 参数传递方法和电子设备
CN118467064B (zh) * 2024-07-01 2024-10-29 北京壁仞科技开发有限公司 参数传递方法和电子设备

Also Published As

Publication number Publication date
CN113939805A (zh) 2022-01-14

Similar Documents

Publication Publication Date Title
WO2021217529A1 (zh) 一种进程间通信的方法及系统
EP3358463B1 (en) Method, device and system for implementing hardware acceleration processing
US11146508B2 (en) Data processing system
US11093284B2 (en) Data processing system
WO2017114283A1 (zh) 一种在物理主机中处理读/写请求的方法和装置
US11947985B2 (en) Data processing method and apparatus, and server for ensuring consistency of data processing processes of a plurality of containers
JP4171910B2 (ja) 並列処理システム及び並列処理プログラム
CN112148422A (zh) 一种io处理的方法和装置
CN110119304B (zh) 一种中断处理方法、装置及服务器
CN113495795A (zh) 一种进程间通信方法及相关设备
WO2022021896A1 (zh) 一种进程间通信的方法及装置
US20190227918A1 (en) Method for allocating memory resources, chip and non-transitory readable medium
WO2024217333A1 (zh) 一种基于块存储的io访问方法、装置、电子设备及介质
US20240205170A1 (en) Communication method based on user-mode protocol stack, and corresponding apparatus
US9424114B2 (en) Input/output (I/O) processing via a page fault doorbell mechanism
WO2017012339A1 (zh) 资源管理方法及装置
US20240345879A1 (en) Task processing method and apparatus
CN116257471A (zh) 一种业务处理方法及装置
CN116521324B (zh) 中断虚拟化处理方法、装置及电子设备
WO2024007934A1 (zh) 中断处理方法、电子设备和存储介质
Au et al. L4 user manual
CN116418848A (zh) 网络节点的配置和访问请求的处理方法、装置
CN118606079B (zh) 一种基于socket接口的通信方法和系统
EP4411540A1 (en) Data processing method and apparatus, and computing device
CN116820430B (zh) 异步读写方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20934100

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20934100

Country of ref document: EP

Kind code of ref document: A1