CN115480926A - Method, device and equipment for synchronizing interprocess communication and storage medium - Google Patents

Method, device and equipment for synchronizing interprocess communication and storage medium Download PDF

Info

Publication number
CN115480926A
CN115480926A CN202211145873.2A CN202211145873A CN115480926A CN 115480926 A CN115480926 A CN 115480926A CN 202211145873 A CN202211145873 A CN 202211145873A CN 115480926 A CN115480926 A CN 115480926A
Authority
CN
China
Prior art keywords
virtual address
offset
space virtual
user space
ipc
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202211145873.2A
Other languages
Chinese (zh)
Inventor
左红明
余文兵
胡志刚
陈凌君
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zebred Network Technology Co Ltd
Original Assignee
Zebred Network Technology Co Ltd
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 Zebred Network Technology Co Ltd filed Critical Zebred Network Technology Co Ltd
Priority to CN202211145873.2A priority Critical patent/CN115480926A/en
Publication of CN115480926A publication Critical patent/CN115480926A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

The application provides a method, a device, equipment and a storage medium for synchronizing interprocess communication, and relates to the computer communication technology. The first process calls a synchronous IPC sending interface to send first process data to the second process, and the first process data are stored in a first process user space virtual address; converting the first process user space virtual address into a first process kernel space virtual address based on the first offset and the second offset; converting the second process user space virtual address into a second process kernel space virtual address based on the third offset and the second offset, and completing copying of the first process data according to the first process kernel space virtual address and the second process kernel space virtual address; and the physical addresses corresponding to the first process user space virtual address and the second process user space virtual address are continuous. The time overhead of the IPC data transmission is saved, and the data transmission performance is improved.

Description

Method, device and equipment for synchronizing interprocess communication and storage medium
Technical Field
The present application relates to computer communication technologies, and in particular, to a method, an apparatus, a device, and a storage medium for synchronizing interprocess communication.
Background
Inter-Process Communication (IPC) is a mechanism for synchronously transmitting data between different processes in a Microkernel Operating System (MOS), and plays an important role in the conversion from a Real-Time Operating System (RTOS) to a complete Portable Operating System (POSIX). In the microkernel operating system architecture, different user processes communicate based on the synchronous IPC, for example, a Process manager communicates with a file system through the synchronous IPC. Therefore, synchronizing IPC is considered a major factor in the runtime overhead of an application, which determines the performance of the application on the microkernel.
In the related art, a first process and a second process respectively call a memory allocation function to allocate a virtual memory. When the first process transmits data to the second process through the synchronous IPC, mapping the user space virtual address of the first process to the user space virtual address corresponding to the second process, and copying the data according to the mapped user space virtual address to realize the synchronous IPC of the first process and the second process.
However, when the above-mentioned techniques are used to implement the synchronous IPC of the first process and the second process, there is a large time overhead, thereby affecting the real-time performance of the synchronous IPC.
Disclosure of Invention
The application provides a method, a device, equipment and a storage medium for communication among synchronous processes, which can save the time overhead of IPC data transmission and improve the data transmission performance of IPC.
In a first aspect, the present application provides a method for synchronizing interprocess communication, including: the first process calls a synchronous IPC sending interface to send first process data to the second process, and the first process data are stored in a first process user space virtual address; when the first process receives a receiving instruction from the second process, the first process converts the first process user space virtual address into a first process kernel space virtual address based on the first offset and the second offset; when the second process receives the sending instruction from the first process, the second process converts the user space virtual address of the second process into the kernel space virtual address of the second process based on the third offset and the second offset, and completes the copying of the first process data according to the kernel space virtual address of the first process and the kernel space virtual address of the second process; the physical addresses corresponding to the virtual addresses in the first process user space and the virtual addresses in the second process user space are continuous, the first offset is the offset of the virtual addresses in the first process user space relative to the physical addresses, the second offset is the fixed offset of the virtual addresses in the kernel space relative to the physical addresses, and the third offset is the offset of the virtual addresses in the second process user space relative to the physical addresses.
Optionally, the converting, by the first process, the first process user space virtual address into the first process kernel space virtual address based on the first offset and the second offset includes: a first process calls a first function to convert a first process user space virtual address into a first process kernel space virtual address; the first function is: kva1= va1-pool1_ offset + physvirt _ offset, where Kva1 denotes a first process kernel space virtual address, va1 denotes a first process user space virtual address, pool1_ offset denotes a first offset, and physvirt _ offset denotes a second offset.
Optionally, the converting, by the second process, the user space virtual address of the second process into the kernel space virtual address of the second process based on the third offset and the second offset includes: the second process calls a second function to convert the user space virtual address of the second process into the kernel space virtual address of the second process; the second function is: kva2= va2-pool2_ offset + physvirt _ offset, where Kva2 represents the second process kernel-space virtual address, va2 represents the second process user-space virtual address, pool2_ offset represents the third offset, and physvirt _ offset represents the second offset.
Optionally, completing the copying of the first process data according to the virtual address of the first process kernel space and the virtual address of the second process kernel space, including: and the second process completes the copying of the first process data through the memory copy function according to the virtual address of the kernel space of the first process, the virtual address of the kernel space of the second process and the size of the first process data.
Optionally, when the first process needs to perform the synchronized IPC, the first process calls the first allocation interface to obtain the user space virtual address of the first process, the first allocation interface is used to allocate the user space virtual memory corresponding to the continuous physical addresses to the process in the synchronized IPC pool, and the synchronized IPC pool is allocated to the first process when the synchronized IPC pool is initialized.
Optionally, when allocating the first process user space virtual address to the first process, the first allocation interface is specifically configured to: the first distribution interface checks whether the idle memory in the synchronous IPC pool meets the virtual memory requirement of the first process; and if so, allocating a user space virtual memory for the first process from the synchronous IPC pool to obtain a user space virtual address of the first process.
Optionally, the first distribution interface is further configured to: when the idle memory in the synchronous IPC pool does not meet the virtual memory requirement of the first process, the first distribution interface distributes a user space virtual memory for the first process by calling a memory distribution function to obtain a third user space virtual memory, wherein the third user space virtual memory is discontinuous corresponding to the physical address; the method further comprises the following steps: when the first process needs to send the first process data to the second process, the first process calls the synchronous IPC sending interface to send a third user space virtual address for storing the first process data to the second process.
Optionally, before the first process uses the synchronized IPC, the first process performs synchronized IPC pool initialization, where the synchronized IPC pool initialization is used to allocate a synchronized IPC pool for the first process from the process virtual address space, allocate a physical address for the first process in the reserved physical memory, map the physical address to the synchronized IPC pool, record the first offset, and the reserved physical memory is a continuous physical memory reserved in the kernel during kernel initialization.
In a second aspect, an embodiment of the present application further provides a device for synchronizing inter-process communication, including: the sending module is used for calling the synchronous IPC sending interface through the first process to send first process data to the second process, and the first process data are stored in a first process user space virtual address; the processing module is used for converting the user space virtual address of the first process into the kernel space virtual address of the first process based on the first offset and the second offset through the first process when the first process receives the receiving instruction from the second process; when the second process receives the sending instruction from the first process, the second process converts the user space virtual address of the second process into the kernel space virtual address of the second process based on the third offset and the second offset, and the second process copies the first process data according to the kernel space virtual address of the first process and the kernel space virtual address of the second process; the physical addresses corresponding to the first process user space virtual address and the second process user space virtual address are continuous, the first offset is the offset of the first process user space virtual address relative to the physical address, the second offset is the fixed offset of the kernel space virtual address relative to the physical address, and the third offset is the offset of the second process user space virtual address relative to the physical address.
In a third aspect, an embodiment of the present application further provides an electronic device, including: a memory and a processor; a memory for storing program instructions and data; a processor for invoking program instructions to perform aspects of the method for synchronizing interprocess communication as provided by the first aspect above.
In a fourth aspect, an embodiment of the present application further provides a readable storage medium, where the readable storage medium has program instructions stored thereon; the program instructions, when executed, implement aspects of the method of synchronous interprocess communication as provided above in the first aspect.
In a fifth aspect, the present application further provides a computer program product, where the computer program product includes a computer program, and when the computer program is executed, the solution of the method for synchronous interprocess communication as described in the above first aspect is implemented.
According to the method, the device, the equipment and the storage medium for synchronizing the interprocess communication, the virtual address space with continuous physical addresses is distributed for the process, and the user space virtual addresses of the process are respectively converted into the kernel space virtual addresses based on the offset of the user space virtual addresses of the process relative to the physical addresses and the offset of the kernel space virtual addresses relative to the physical addresses, so that the synchronous IPC of data is realized. Because the physical addresses corresponding to the virtual addresses of the data stored in the two processes of the IPC are continuous, the operation of converting the user space virtual addresses of the processes into the kernel space virtual addresses respectively can be realized only by simple calculation, thereby saving the time overhead of data transmission of the IPC and improving the data transmission performance of the IPC.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.
Fig. 1 is a diagram illustrating an application scenario of a synchronous interprocess communication method according to an embodiment of the present application;
fig. 2 is a first flowchart illustrating a synchronization inter-process communication method according to an embodiment of the present disclosure;
fig. 3 is a second flowchart illustrating a synchronous interprocess communication method according to an embodiment of the present application;
fig. 4 is a schematic diagram illustrating an initialization memory mapping of a synchronous interprocess communication method according to an embodiment of the present application;
fig. 5 is a schematic diagram illustrating memory allocation of a synchronous interprocess communication method according to an embodiment of the present application;
FIG. 6 is a schematic structural diagram of a synchronous interprocess communication device according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Specific embodiments of the present application have been shown by way of example in the drawings and will be described in more detail below. The drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the concepts of the application by those skilled in the art with reference to specific embodiments.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
To facilitate understanding of the embodiments of the present application by those skilled in the art, first, terms referred to in the embodiments of the present application will be described:
each process is allocated with its own virtual address space and can only access the virtual address space allocated for use by itself to achieve process isolation.
Mapping exists between a virtual address space and a physical address space, the mapping is completed through a Memory Management Unit (MMU), and a process can indirectly operate the physical address space by operating its own virtual address space.
The user space (user space) is a space in which a user program runs, and the kernel space (kernel space) is a space in which a system kernel runs. The current operating systems are all virtual memories, and for a 32-bit operating system, the virtual address space of the virtual memory is 32 powers of 2, namely 4GB. The kernel of the operating system is a kernel, which is independent of common applications, and can access the protected virtual address space and also access the underlying hardware devices. In order to protect the user process from directly operating the kernel and ensure the safety of the kernel, the operating system logically divides the virtual address space into a user space and a kernel space. For the Linux operating system, the highest 1GB byte is used by the kernel, called kernel space, and the lower 3GB bytes are used by the processes, called user space. Wherein processes share kernel space.
And the user state is the process running in the user space.
And the kernel state is the process running in the kernel space. In kernel mode, the CPU can access all data of the memory, including peripheral devices, and can also switch itself from one process to another.
Although the virtual address space is logically divided into the user space and the kernel space by the operating system, some processes running in the user space inevitably need to access resources of the kernel space, and the system call is the only way for the processes in the user space to access the kernel space, so that all operations are ensured to be performed under the control of the kernel, the unauthorized access of the processes in the user space to the kernel space is avoided, and the safety and the stability of the system are improved.
A Client/Server (Client/Server, abbreviated as C/S) model is a typical IPC model. In the C/S model, the processes of the two communication parties are a client process and a server process respectively.
Next, a specific implementation of data communication between the client process and the server process through synchronous IPC will be described by taking a C/S model as an example.
When data communication is performed between the client process and the server process through the synchronous IPC, since most operating systems and use scenarios start the MMU and the MMU causes the two ends not to belong to the same virtual address space, data copy cannot be performed through the virtual addresses of the two ends of the client process and the server process.
Based on the above, for data transmission between the client process and the server process, the general method is to perform two copies: and copying data from the user space virtual address of the client process to the kernel space virtual address, and copying the data from the kernel space virtual address to the user space virtual address of the server process. Making two copies of data for large data incurs a large performance overhead. Moreover, since the kernel does not know how much data to transmit, the size of the virtual address in the kernel space is difficult to determine, and if a memory is temporarily applied, a large performance overhead is brought. In addition, uncertainty is generated on the temporary memory allocation of the microkernel in the intelligent driving field, and the functional safety standard is not met.
Or, aiming at the data transmission of the client process and the server process, the virtual address mapping and the one-time copy are used for realizing: and mapping the user space virtual address of the client process to the user space virtual address corresponding to the server process in a software mode, and executing data copying once according to the mapped user space virtual address. However, in this implementation, the page table of the address mapping operation incurs a large time overhead.
Aiming at the problem of large time overhead in the related technology, the application provides a method, a device, equipment and a storage medium for communication among synchronous processes, a fast buffer (fast buffer) corresponding to continuous physical addresses is introduced, and data transmission can be completed through one-time virtual address mapping and one-time data copying, wherein the virtual address mapping is realized through address offset.
Compared with a scheme of copying data twice, the method reduces one-time data copying, can save larger data copying time overhead, and realizes the performance optimization of the IPC; compared with the scheme of one-time virtual address mapping and one-time data copying, the method optimizes the logic of virtual address mapping, can complete the virtual address mapping only by one statement, does not need to complete the address mapping by a complex logic operation page table, can save time overhead caused by larger address mapping, and realizes the performance optimization of the synchronous IPC. It can be understood that the larger the data volume to be transmitted, the better the synchronous IPC performance optimization effect of the application is.
The method and the device can be applied to the technical fields of intelligent driving and the like. For the field of intelligent driving, the effects of guaranteeing functional safety, maintaining personal and property safety, ensuring timely response of an intelligent driving assembly and ensuring Real-Time performance of a Real Time Operating System (RTOS for short) can be achieved.
Fig. 1 is a diagram illustrating an application scenario of a synchronous interprocess communication method according to an embodiment of the present application. As shown in fig. 1, in a multi-process operating system, each process is allocated with an independent virtual memory (or virtual address space), so that the processes are isolated from each other, and this isolation is to avoid the processes (e.g., the first process and the second process in fig. 1) from affecting each other. The processes are isolated through a virtual address space, and particularly, the virtual address space of the first process is different from the virtual address space of the second process, so that the first process can be prevented from modifying data in the second process. A process may indirectly operate on physical memory (or physical address space) by operating on its own virtual address space.
The virtual address space can be divided into a user space and a kernel space, and a user process runs in the user space (user state) and cannot directly access the physical memory; the kernel process runs in the kernel space (kernel mode), and can access resources of the kernel space, such as operations of accessing a physical memory, and the like, and the user process can execute system call to enter the kernel space from the user space. Where kernel space is shared by all processes. The process is in the user space before being executed or after being released, and enters the kernel space when being executed, namely, the process is switched from the user mode to the kernel mode. User spaces of different processes are mapped to different physical memory areas, and kernel spaces are mapped to the same physical memory area.
The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 2 is a first flowchart illustrating a synchronization inter-process communication method according to an embodiment of the present disclosure. As shown in fig. 2, the method for communication between synchronous processes includes:
s201: and the first process calls the synchronous IPC sending interface to send first process data to the second process, and the first process data are stored in the first process user space virtual address.
In this embodiment, data is sent by a first process to a second process. For example, the first process may be initiated by an application program corresponding to a Client (Client side), and the second process may be initiated by an application program corresponding to a Server (Server side). The first process is distributed with a first process user space virtual address, the second process is distributed with a second process user space virtual address, and the first process user space virtual address and the second process user space virtual address correspond to a continuous physical address.
The first process data is written to the user space by the first process. Optionally, the first process may apply for allocating a segment of user space virtual address, and store the first process data therein, where the segment of user space virtual address applied for allocation by the first process is the first process user space virtual address. When the first process needs to send the first process data to the second process, the first process calls the synchronous IPC sending interface to send the first process data to the second process.
For example, the synchronous IPC sending interface may be implemented by using a send () function, and the first process calls the send () function to send the first process data to the second process. And then, the first process enters a kernel state by system call, waits for the second process to release the receiving indication and enters a waiting (pending) state. Wherein the reception indication is used to inform the first process of the status that its reception was successful.
In some embodiments, the second process may use a receive () function as a synchronous IPC receiving interface to receive the first process data sent by the first process. And then, the second process enters a kernel state by system call, releases the receiving indication, activates the first process to obtain scheduling, waits for the first process to release the sending indication and enters a waiting (pending) state.
Optionally, the second user space virtual address may be the same as or different from the first user space virtual address in space size.
The offset of the user space virtual address of the first process relative to the physical address is a first offset, and the first offset is determined when the first process is initialized and can be inquired and recorded by the first process; the offset of the user space virtual address of the second process relative to its physical address is a third offset, which is determined at initialization of the second process, and the third offset may be queried and recorded by the second process.
S202: when the first process receives a receiving instruction from the second process, the first process converts the first process user space virtual address into the first process kernel space virtual address based on the first offset and the second offset.
The second offset is a fixed offset of the virtual address of the kernel space relative to the physical address, and the second offset is determined when the kernel is initialized.
Optionally, the first process changes from the waiting (pending) state to the running (running) state in response to receiving the receiving indication from the second process. And then, the first process converts the user space virtual address of the first process into the kernel space virtual address of the first process according to the first offset and the second offset.
Illustratively, the first process may call an address translation function to implement the address translation described above. Because the virtual address of the first process user space corresponds to the physically continuous memory, the virtual address mapping can be completed only by simple mathematical calculation.
And after the first process converts the user space virtual address of the first process into the kernel space virtual address of the first process, releasing the sending instruction, activating the second process to obtain scheduling, waiting for the second process to release the reply instruction, and enabling the first process to enter a waiting (pending) state.
S203: and when the second process receives the sending instruction from the first process, the second process converts the user space virtual address of the second process into the kernel space virtual address of the second process based on the third offset and the third offset, and completes the copying of the first process data according to the kernel space virtual address of the first process and the kernel space virtual address of the second process.
Optionally, after receiving the sending instruction from the first process, the second process changes from a waiting (pending) state to a running (running) state; and then, converting the second process user space virtual address into a second process kernel space virtual address, and finishing the copying of the first process data according to the first process kernel space virtual address and the second process kernel space virtual address.
Illustratively, the second process may call an address translation function to implement the address translation described above. Similarly, since the virtual address in the user space of the second process corresponds to the physically continuous memory, the virtual address mapping can be completed only by simple mathematical calculation.
Optionally, when the second process completes the copying of the data according to the virtual address of the first process kernel space and the virtual address of the second process kernel space, the method may specifically include: and the second process completes the copying of the first process data through the memory copy function according to the virtual address of the kernel space of the first process, the virtual address of the kernel space of the second process and the size of the first process data. Illustratively, the second process may complete the data copy by memcpy (Kva 2, kva1, size), kva2 representing the second process kernel space virtual address, kva1 representing the first process kernel space virtual address, and size representing the data size.
Optionally, after the data copy is completed, the second process calls a reply () interface to release the reply indication, notifies the first process that the synchronized IPC is finished, and ends the second process. Correspondingly, after receiving the reply indication, the first process changes from a waiting (pending) state to a running (running) state, and ends the first process.
In the embodiment of the application, on the premise of ensuring that physical addresses corresponding to virtual addresses of two processes for storing data of the IPC are continuous, the user space virtual addresses of the processes are converted into kernel space virtual addresses respectively based on the offset of the user space virtual addresses of the processes relative to the physical addresses and the offset of the kernel space virtual addresses relative to the physical addresses, so that the IPC of the data is synchronized. Because the physical addresses are continuous, the operation of respectively converting the user space virtual addresses of the processes into the kernel space virtual addresses can be realized only by simple calculation, thereby saving the time overhead of the data transmission of the synchronous IPC and improving the data transmission performance of the synchronous IPC.
In the above embodiment, when converting a first process user space virtual address into a first process kernel space virtual address based on a first offset and a second offset, or converting a second process user space virtual address into a second process kernel space virtual address based on a third offset and a second offset, the following may be implemented in a variety of ways, for example:
in one example, a first process translating a first process user space virtual address to a first process kernel space virtual address based on a first offset and a second offset may include: the first process calls a first function to convert the first process user space virtual address into a first process kernel space virtual address.
Wherein the first function may be:
Kva1=va1-pool1_offset+physvirt_offset
where Kva1 represents a first process kernel space virtual address, va1 represents a first process user space virtual address, pool1_ offset represents a first offset, and physvirt _ offset represents a second offset.
Optionally, in the foregoing embodiment, the translating, by the second process, the second process user space virtual address into the second process kernel space virtual address based on the third offset and the second offset may include: and the second process calls a second function to convert the user space virtual address of the second process into the kernel space virtual address of the second process. Wherein the second function may be:
Kva2=va2-pool2_offset+physvirt_offset
where Kva2 represents the second process kernel space virtual address, va2 represents the second process user space virtual address, pool2_ offset represents the third offset, and physvert _ offset represents the second offset.
The above does not limit the present application, and other formulas can be obtained by simply modifying the above formulas, for example.
Further, a second offset is determined at kernel initialization, which may be obtained by performing the following function query:
adrx0,physvirt_offset;ldrx1,=physvirt_offset;subx1,x1,x0;strx1,[x0],
wherein x0 is the physical address of the kernel space, x1 is the virtual address of the kernel space, and the second offset from the virtual address to the physical address can be obtained by subtracting x0 from x 1. The second offset is recorded.
Fig. 3 is a flowchart illustrating a second method for communication between synchronous processes according to an embodiment of the present disclosure. As shown in fig. 3, the method for communication between synchronous processes includes:
s301: the first process initializes the synchronous IPC pool of the process and records the first offset pool1_ offset.
Before the first process uses synchronous IPC, the first process executes synchronous IPC pool initialization, the synchronous IPC pool initialization is used for allocating a synchronous IPC pool for the first process from a process virtual address space, allocating a physical address for the first process in a reserved physical memory, mapping the physical address to the synchronous IPC pool, recording a first offset, and the reserved physical memory is a continuous physical memory reserved in a kernel when the kernel is initialized.
Fig. 4 illustrates an initialization memory mapping schematic diagram of the synchronous inter-process communication method provided in the embodiment of the present application, and in conjunction with fig. 4, when the kernel initializes, a continuous physical memory (for example, the P area shown in fig. 4) is reserved in the kernel, and the physical memory is mapped to the kernel space (shaded portion) by a fixed offset. The first process executing the synchronous IPC pool initialization process specifically comprises the following steps: before the first process uses the synchronous IPC, the synchronous IPC pool initialization is executed, a continuous 16KB space is allocated from the corresponding user space virtual address to serve as the synchronous IPC pool of the process, and a continuous memory with the size of 16KB is allocated on the physical address P and is mapped to the synchronous IPC pool of the first process. It should be noted that each process has an independent synchronous IPC pool, and the size of each process can be configured by an application according to an actual use scenario, and the size of 16KB illustrated in this embodiment is only an example, and does not limit the technical solution of the present application.
The first process records a first offset of a first process user space virtual address relative to its physical address. Optionally, the first process may obtain the first process user space virtual address by executing the following address initialization function:
va = vm _ init (SYNC _ IPC _ POOL _ SIZE, false, & phys), where SYNC _ IPC _ POOL _ SIZE represents the SIZE of the synchronized IPC POOL of a process, and phys represents the physical address corresponding to the user space virtual address of the process. Based on the returned va, the offset is calculated according to the following formula:
pool_offset=phys–va。
s302: the second process initializes the synchronous IPC pool of the process and records the third offset pool2_ offset.
Similar to S301, before the second process uses synchronized IPC, the second process performs synchronized IPC pool initialization. And the synchronous IPC pool initialization is used for distributing a second process user space virtual address for the second process from the process virtual address space, distributing a physical address for the second process in the reserved physical memory and mapping the physical address to the second process user space virtual address. The reserved physical memory is a continuous physical memory reserved in the kernel when the kernel is initialized.
In connection with FIG. 4, the synchronized IPC pool initialization of the second process corresponds to step S301, which is performed before the second process uses synchronized IPC. Illustratively, the synchronous IPC pool of the second process initializes a block of continuous 16KB space allocated from the corresponding user space virtual address as the synchronous IPC pool of the process, and allocates a block of continuous memory with a size of 16KB on the physical address P, which is mapped to the synchronous IPC pool of the second process.
The second process records a third offset pool2_ offset of the second process user space virtual address relative to its physical address. Optionally, the second process may also obtain the virtual address and the physical address of the user space of the second process through the address initialization function.
S303: the first process calls a first allocation interface to obtain a first process user space virtual address va1 and records the va1; data is written va1.
S304: and the second process calls the first distribution interface to obtain a virtual address va2 of the user space of the second process and records the va2.
When the first process needs to carry out IPC synchronization, the first process calls a first allocation interface to obtain a user space virtual address of the first process, the first allocation interface is used for allocating user space virtual memory corresponding to continuous physical addresses for the processes in the IPC synchronization pool, and the IPC synchronization pool is allocated for the first process when the IPC synchronization pool is initialized. Specifically, the first distribution interface preferentially allocates space from the synchronous IPC pool. The first process writes the data to be sent to the second process into the first process user space virtual address va1. Similarly, when the second process needs to perform synchronous IPC, the second process calls the first allocation interface to obtain the user space virtual address of the second process, and the first allocation interface is used for allocating the user space virtual memory corresponding to the continuous physical address for the process.
Optionally, when allocating the first process user space virtual address to the first process, the first allocation interface is specifically configured to: the first distribution interface checks whether the idle memory in the synchronous IPC pool meets the virtual memory requirement of the first process; and if so, allocating a user space virtual memory for the first process from the synchronous IPC pool to obtain a user space virtual address of the first process. That is, the first allocation interface preferentially allocates space from the synchronous IPC pool. The first distribution interface checks the idle memory condition in the synchronous IPC pool, judges whether the idle memory can distribute complete first process user space, if yes, preferentially distributes user space virtual memory for the first process from the synchronous IPC pool to obtain a first process user space virtual address.
Optionally, the first allocation interface is further configured to: when the free memory in the synchronous IPC pool does not meet the virtual memory requirement of the first process, the first distribution interface distributes a user space virtual memory for the first process by calling a memory distribution function to obtain a third user space virtual memory, wherein the third user space virtual memory is discontinuous corresponding to the physical address; and when the first process needs to send data to the second process, the first process calls the synchronous IPC sending interface to send a third user space virtual address for storing the data to the second process. That is, when the first allocating interface detects that the free memory in the synchronous IPC pool is not enough to allocate the complete user space of the first process, it calls a memory allocation function, such as malloc () function, to allocate space to the ordinary memory area outside the synchronous IPC pool as a supplement.
Fig. 5 illustrates a schematic memory allocation diagram of the synchronous inter-process communication method provided in the embodiment of the present application, and as shown in fig. 5, when allocating a virtual address to a process, a first allocation interface preferentially calls a pool allocation interface to allocate a space from a synchronous IPC pool, for example, a complete 16KB space is allocated from the synchronous IPC pool, and physical addresses corresponding to the 16KB virtual memory are consecutive. When the first allocation interface detects that the free memory in the synchronous IPC pool cannot allocate a complete 16KB space, the common allocation interface is called to allocate a space from a common memory region outside the synchronous IPC pool as a supplement, for example, a malloc function is called to allocate to obtain a third user space virtual memory, and a physical address corresponding to the third user space may be discontinuous.
S305: the first process calls the synchronous IPC send interface send (). For sending the first process data to the second process.
At this time, the first process data is not actually transmitted but in a transmission state. And then, the first process enters a waiting (pending) state from a running (running) state, and waits for receiving a receiving indication recv _ call released by the second process.
S306: the second process calls the synchronous IPC receive interface receive ().
The first process and the second process enter the kernel mode from the user mode.
S307: the second process sends a receive indication recv semaphore to the first process.
After that, the second process enters a waiting (pending) state from the running (running) state, and waits for receiving the send indication send _ multimedia released by the first process.
S308: the first process calls a first function to convert the first process user space virtual address va1 into the first process kernel space virtual address Kva1.
S309: the first process sends a send indication send _ multimedia to the second process.
Thereafter, the first process enters a waiting (pending) state from the running state, and waits for receiving a completion indication reply _ map released by the second process.
S310: and the second process calls a second function to convert the user space virtual address va2 of the second process into the kernel space virtual address Kva2 of the second process.
S311: the second process calls the copy function memcpy (Kva 2, kva1, size) to complete the data copy.
S312: the second process calls the reply () interface, sending a completion indication reply _ map to the first process.
And then, the second process finishes the process, the first process receives the completion indication reply _ call, the process is finished, and the first process and the second process reenter the user mode from the kernel mode to wait for the next task.
S305-S312 correspond to steps S201-S203, and respectively convert the user space virtual addresses of the processes into kernel space virtual addresses based on the offsets of the user space virtual addresses of the processes relative to the physical addresses and the offsets of the kernel space virtual addresses relative to the physical addresses, thereby implementing the copying of data between kernel spaces, where specific relevant descriptions are as described above and are not repeated here.
In the embodiment of the application, on the premise of ensuring continuity of physical addresses corresponding to virtual addresses of stored data of a synchronous process, the user space virtual addresses of the process are respectively converted into kernel space virtual addresses based on the offset of the user space virtual addresses of the process relative to the physical addresses and the offset of the kernel space virtual addresses relative to the physical addresses, so that copying of the data between kernel spaces is realized. Because the virtual addresses are continuous corresponding to the physical addresses, the operation of respectively converting the user space virtual addresses of the process into the kernel space virtual addresses can be realized only by simple calculation without operating a page table or copying for many times, thereby saving the time overhead of IPC data transmission and improving the data transmission performance of the IPC.
Preferably, when the synchronous IPC pool is initialized, enough memory space is allocated to the synchronous IPC pool, so that each process can allocate a complete virtual memory from the synchronous IPC pool. The embodiment can further reduce the time overhead of the synchronous IPC data transmission because a large performance overhead exists when the address mapping is carried out by using the common memory allocated by malloc, and the size of the synchronous IPC pool is adjusted as much as possible for the process sensitive to the synchronous IPC performance, so that the size of the synchronous IPC pool can meet the requirement that the process uses most scenes of the synchronous IPC, and the synchronous IPC performance optimization is obtained as much as possible.
The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.
Fig. 6 is a schematic structural diagram of a synchronous interprocess communication device according to an embodiment of the present application. As shown in fig. 6, the synchronous interprocess communication apparatus includes:
a sending module 601, configured to call a synchronous IPC sending interface through a first process to send first process data to a second process, where the first process data is stored in a first process user space virtual address;
a processing module 602, configured to, when the first process receives a reception instruction from the second process, convert, by the first process, the first process user space virtual address into a first process kernel space virtual address based on the first offset and the second offset; when the second process receives the sending instruction from the first process, the second process converts the user space virtual address of the second process into the kernel space virtual address of the second process based on the third offset and the second offset, and the second process copies the first process data according to the kernel space virtual address of the first process and the kernel space virtual address of the second process;
the physical addresses corresponding to the virtual addresses in the first process user space and the virtual addresses in the second process user space are continuous, the first offset is the offset of the virtual addresses in the first process user space relative to the physical addresses, the second offset is the fixed offset of the virtual addresses in the kernel space relative to the physical addresses, and the third offset is the offset of the virtual addresses in the second process user space relative to the physical addresses.
In a possible implementation, the processing module 602 may be specifically configured to: calling a first function, and converting a first process user space virtual address into a first process kernel space virtual address; the first function is: kva1= va1-pool1_ offset + physvirt _ offset, where Kva1 denotes a first process kernel space virtual address, va1 denotes a first process user space virtual address, pool1_ offset denotes a first offset, and physvirt _ offset denotes a second offset.
In a possible implementation, the processing module 602 may further specifically be configured to: calling a second function to convert the user space virtual address of the second process into the kernel space virtual address of the second process; the second function is: kva2= va2-pool2_ offset + physvirt _ offset, where Kva2 represents the second process kernel-space virtual address, va2 represents the second process user-space virtual address, pool2_ offset represents the third offset, and physvirt _ offset represents the second offset.
In a possible implementation, the processing module 602 may be further specifically configured to: and according to the virtual address of the kernel space of the first process, the virtual address of the kernel space of the second process and the size of the data of the first process, finishing the copying of the data of the first process through a memory copy function.
In a possible implementation, the sending module 601 may specifically be configured to: and calling a first allocation interface to obtain a first process user space virtual address, wherein the first allocation interface is used for allocating a user space virtual memory corresponding to the continuous physical address for the process.
In a possible implementation manner, the sending module 601 may be further specifically configured to: calling a first distribution interface to check whether the idle memory in the synchronous IPC pool meets the virtual memory requirement of a first process; and if so, allocating a user space virtual memory for the first process from the synchronous IPC pool to obtain a user space virtual address of the first process.
In a possible implementation manner, the sending module 601 may be further specifically configured to: when the idle memory in the synchronous IPC pool does not meet the virtual memory requirement of the first process, the first distribution interface distributes a user space virtual memory for the first process by calling a memory distribution function to obtain a third user space virtual memory, wherein the third user space virtual memory is discontinuous corresponding to the physical address; when the first process needs to send the first process data to the second process, the first process calls the synchronous IPC sending interface to send a third user space virtual address for storing the first process data to the second process.
Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Referring to fig. 7, the electronic device 700 includes: a processor 701, a memory 702, and a system bus 703.
The memory 702 is connected to the processor 701 through the system bus 703 and performs communication with each other, the memory 702 is used for storing program instructions and data, and the processor 701 is used for calling the program instructions in the memory to execute the scheme of the synchronous interprocess communication method as the above-mentioned method embodiment.
In particular, processor 701 may include one or more processing units, such as: the Processor 701 may be a Central Processing Unit (CPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the methods disclosed in the incorporated application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.
Memory 702 may be used to store program instructions and data. The memory 702 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function) required by at least one function, and the like. The storage data area may store data (e.g., first process data, etc.) created during use of the electronic device 700, and the like. In addition, the memory 702 may include a high speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a Universal Flash Storage (UFS), and the like. The processor 701 executes various functional applications of the electronic device 700 and data processing by executing program instructions stored in the memory 702.
The system bus 703 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The system bus 703 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.
It should be noted that, regarding the number of the memories 702 and the processors 701, the embodiments of the present application do not limit them, and they may be one or more, and fig. 7 illustrates one example; the memory 702 and the processor 701 may be connected to each other by a wire in various ways, for example, by a bus. In practice, the electronic device 700 may be a computer or a mobile terminal in various forms. Wherein the computer is, for example, a laptop computer, a desktop computer, a workbench, a server, a blade server, a mainframe computer, etc.; mobile terminals are, for example, personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices.
The electronic device of this embodiment may be configured to implement the technical solutions in the method embodiments, and the implementation principle and the technical effects are similar, which are not described herein again.
The embodiment of the present application further provides a readable storage medium, where a computer program is stored on the readable storage medium, and when the computer program is executed, the scheme of the above synchronization inter-process communication method is implemented, for example, the synchronization inter-process communication method may be implemented by computer software, and the corresponding software may be stored in the readable storage medium, for example, a hard disk, an optical disk, or a floppy disk of a computer.
Embodiments of the present application further provide a computer program product, which contains a computer program, and when the computer program is executed, the scheme of the method for synchronizing interprocess communication as above is implemented.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, etc.
Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and these modifications or substitutions do not depart from the scope of the technical solutions of the embodiments of the present application.

Claims (11)

1. A method for synchronizing interprocess communication, comprising:
a first process calls an IPC sending interface for synchronous inter-process communication to send first process data to a second process, and the first process data is stored in a first process user space virtual address;
when the first process receives a receiving instruction from the second process, the first process converts the first process user space virtual address into a first process kernel space virtual address based on a first offset and a second offset;
when the second process receives a sending instruction from the first process, the second process converts a second process user space virtual address into a second process kernel space virtual address based on a third offset and the second offset, and copies the first process data according to the first process kernel space virtual address and the second process kernel space virtual address;
the physical addresses corresponding to the first process user space virtual address and the second process user space virtual address are continuous, the first offset is an offset of the first process user space virtual address relative to the physical address, the second offset is a fixed offset of the kernel space virtual address relative to the physical address, and the third offset is an offset of the second process user space virtual address relative to the physical address.
2. The method of claim 1, wherein the first process translating the first process user space virtual address to a first process kernel space virtual address based on a first offset and a second offset comprises:
the first process calls a first function to convert the user space virtual address of the first process into a kernel space virtual address of the first process;
the first function is: kva1= va1-pool1_ offset + physvirt _ offset, where Kva1 denotes the first process kernel space virtual address, va1 denotes the first process user space virtual address, pool1_ offset denotes the first offset, and physvirt _ offset denotes the second offset.
3. The method of claim 1, wherein the second process translating the second process user space virtual address to a second process kernel space virtual address based on a third offset and the second offset comprises:
the second process calls a second function to convert the user space virtual address of the second process into a kernel space virtual address of the second process;
the second function is: kva2= va2-pool2_ offset + physvirt _ offset, where Kva2 represents the second process kernel-space virtual address, va2 represents the second process user-space virtual address, pool2_ offset represents the third offset, and physvirt _ offset represents the second offset.
4. The method of any of claims 1 to 3, wherein said completing the copying of the first process data according to the first process kernel space virtual address and the second process kernel space virtual address comprises:
and the second process completes the copy of the first process data through a memory copy function according to the first process kernel space virtual address, the second process kernel space virtual address and the size of the first process data.
5. The method of any of claims 1 to 3, further comprising:
when a first process needs to carry out IPC synchronization, the first process calls a first allocation interface to obtain a user space virtual address of the first process, the first allocation interface is used for allocating user space virtual memory corresponding to continuous physical addresses for the process in a synchronous IPC pool, and the synchronous IPC pool is allocated for the first process when the synchronous IPC pool is initialized.
6. The method of claim 5, wherein the first assignment interface, when assigning the first process user space virtual address, is specifically configured to:
the first distribution interface checks whether the idle memory in the synchronous IPC pool meets the virtual memory requirement of the first process;
and if so, allocating a user space virtual memory to the first process from the synchronous IPC pool to obtain the first process user space virtual address.
7. The method of claim 6, wherein the first distribution interface is further configured to: when the idle memory in the synchronous IPC pool does not meet the virtual memory requirement of the first process, the first distribution interface distributes a user space virtual memory for the first process by calling a memory distribution function to obtain a third user space virtual memory, wherein the third user space virtual memory is discontinuous corresponding to physical addresses;
the method further comprises the following steps: and when the first process needs to send first process data to the second process, the first process calls a synchronous IPC sending interface to send a third user space virtual address for storing the first process data to the second process.
8. The method of claim 5, further comprising:
before the first process uses IPC, the first process executes IPC pool initialization, the IPC pool initialization is used for allocating an IPC pool for the first process from a process virtual address space, allocating the physical address for the first process in a reserved physical memory, mapping the physical address to the IPC pool, and recording the first offset, wherein the reserved physical memory is a continuous physical memory reserved in a kernel during kernel initialization.
9. A synchronous interprocess communication apparatus, comprising:
the system comprises a sending module, a synchronization inter-process communication module and a synchronization inter-process communication module, wherein the sending module is used for calling an IPC sending interface through a first process to send first process data to a second process, and the first process data are stored in a first process user space virtual address;
a processing module, configured to convert, by the first process, the first process user space virtual address into a first process kernel space virtual address based on a first offset and a second offset when the first process receives a reception instruction from the second process; when the second process receives a sending instruction from the first process, the second process converts a user space virtual address of the second process into a kernel space virtual address of the second process based on a third offset and the second offset, and the second process copies the first process data according to the kernel space virtual address of the first process and the kernel space virtual address of the second process;
the physical addresses corresponding to the first process user space virtual address and the second process user space virtual address are continuous, the first offset is an offset of the first process user space virtual address relative to the physical address, the second offset is a fixed offset of the kernel space virtual address relative to the physical address, and the third offset is an offset of the second process user space virtual address relative to the physical address.
10. An electronic device, comprising: a memory and a processor;
the memory for storing program instructions and data;
the processor for invoking the program instructions to perform the synchronous interprocess communication method of any of claims 1-8.
11. A readable storage medium having program instructions stored thereon; the program instructions, when executed, implement a method of synchronizing interprocess communication according to any of claims 1 to 8.
CN202211145873.2A 2022-09-20 2022-09-20 Method, device and equipment for synchronizing interprocess communication and storage medium Pending CN115480926A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211145873.2A CN115480926A (en) 2022-09-20 2022-09-20 Method, device and equipment for synchronizing interprocess communication and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211145873.2A CN115480926A (en) 2022-09-20 2022-09-20 Method, device and equipment for synchronizing interprocess communication and storage medium

Publications (1)

Publication Number Publication Date
CN115480926A true CN115480926A (en) 2022-12-16

Family

ID=84392557

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211145873.2A Pending CN115480926A (en) 2022-09-20 2022-09-20 Method, device and equipment for synchronizing interprocess communication and storage medium

Country Status (1)

Country Link
CN (1) CN115480926A (en)

Similar Documents

Publication Publication Date Title
CN101847105B (en) Computer and internal memory sharing method of a plurality of operation systems
US20140095769A1 (en) Flash memory dual in-line memory module management
JP5608243B2 (en) Method and apparatus for performing I / O processing in a virtual environment
KR20160097363A (en) Resource processing method, operating system, and device
CN111679921A (en) Memory sharing method, memory sharing device and terminal equipment
WO2023165400A1 (en) Computing system, memory page fault processing method, and storage medium
WO2022021896A1 (en) Interprocess communication method and apparatus
CN113760560A (en) Inter-process communication method and inter-process communication device
CN114356598A (en) Data interaction method and device for Linux kernel mode and user mode
US20240281381A1 (en) Data storage apparatus and data processing method
CN112612623A (en) Method and equipment for managing shared memory
CN111143072B (en) User mode program memory allocation method, system and related components
US20200371827A1 (en) Method, Apparatus, Device and Medium for Processing Data
US20150242121A1 (en) Per-memory group swap device
US20230388371A1 (en) System and method for accessing remote resource
CN117632843A (en) Data processing method and device, system on chip and electronic equipment
US6986017B2 (en) Buffer pre-registration
WO2023109211A9 (en) Service processing method and related apparatus
CN115480926A (en) Method, device and equipment for synchronizing interprocess communication and storage medium
WO2022262623A1 (en) Data exchange method and apparatus
WO2022199560A1 (en) Memory management method and device
CN116418848A (en) Method and device for processing configuration and access requests of network nodes
CN111124506A (en) Operation card driving implementation method based on application layer
CN117632799B (en) Data processing method, device, equipment and storage medium
CN116361033B (en) Communication method, electronic device, and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination