An inter-process communication method and apparatus

Abstract

The embodiment of the specification discloses a process intercommunication method and device, comprising: for any process, establishing a process list in the process; wherein the process list is generated according to process information of a target device; creating a receiving message queue corresponding to the process, and extending the receiving message queue to the process list of the process; when the process needs to communicate with a target process, generating a message structure according to a task to be executed by the target process, sending the message structure to the receiving message queue corresponding to the target process, so that the target process executes the task according to the receiving message queue; wherein the target process executing the task according to the receiving message queue comprises: determining a message structure to be processed according to the receiving message queue, determining a target operation to be executed according to the message structure to be processed, and determining data to be operated from a shared memory, and executing the target operation on the data.

Description

Technical Field

[0001] This application relates to the field of inter-process communication technology, and in particular to an inter-process communication method and apparatus. Background Technology

[0002] In embedded systems, inter-process communication (IPC) scenarios are common. IPC communication methods include signals, pipes, semaphores, shared memory, (inter-process) queues, and sockets. Each of these methods has its own drawbacks in implementing IPC. For example, while shared memory is fast, it lacks a synchronous / asynchronous mechanism, and data integrity cannot be guaranteed when multiple processes are involved. Message queues do not have read order issues, but they consume additional CPU resources when there are many processes, affecting efficiency; they also have low transmission efficiency when dealing with large amounts of data and occupy additional memory. In current technologies, the netconf southbound management process needs to obtain large amounts of data from other processes and perform inter-process communication frequently, consuming significant resources. Summary of the Invention

[0003] This specification provides an inter-process communication method and apparatus to address the technical problem of how to improve the effectiveness and efficiency of inter-process communication.

[0004] To address the aforementioned technical problems, the embodiments in this specification provide the following technical solutions:

[0005] This specification provides an embodiment of an inter-process communication method, the method comprising:

[0006] For any given process, a process list is created for that process; wherein the process list is generated based on the process information of the target device;

[0007] Create a receive message queue corresponding to the process, and expand the receive message queue to the process list of the process;

[0008] When the process needs to communicate with the target process, it generates a message structure according to the task to be executed by the target process, and sends the message structure to the receiving message queue corresponding to the target process, so that the target process can execute the task according to the receiving message queue.

[0009] The target process executing the task according to the received message queue includes:

[0010] The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data.

[0011] Optionally, before generating the message structure according to the task to be executed by the target process, the method further includes:

[0012] Link the process to shared memory that is used by all processes.

[0013] Optionally, before sending the message structure to the receive message queue corresponding to the target process, the method further includes:

[0014] The data that the target process needs to process is placed in shared memory, and the message structure includes the location information of the data in the shared memory.

[0015] Optionally, the method further includes:

[0016] The sending interface of the message structure is determined based on whether the target process needs to return a response message.

[0017] And / or,

[0018] Determine whether the message structure has arrived at the message receiving queue corresponding to the target process within the agreed time;

[0019] If not, the message structure is resent to the message queue corresponding to the target process.

[0020] This specification provides another inter-process communication method, the method comprising:

[0021] For any given process, a process list is created for that process; wherein the process list is generated based on the process information of the target device;

[0022] Create a message queue corresponding to the process, and expand the message queue to the process list of the process; wherein the message queue is used to arrange message structures sent by other processes;

[0023] The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data.

[0024] Optionally, the method further includes:

[0025] After receiving a message structure, check the maximum sequence identifier of the message structures that have not yet been processed, and then assign the next sequence identifier to the newly received message structure.

[0026] Optionally, determining the message structure to be processed based on the received message queue includes:

[0027] The message structure corresponding to the first sorted identifier in the current received message queue is taken as the message structure to be processed.

[0028] After processing each message structure, update the received message queue, and continue to use the message structure corresponding to the first sorted message structure in the updated received message queue as the message structure to be processed.

[0029] Optionally, the method further includes:

[0030] Start the message receiving thread corresponding to the process. The message receiving thread is used to receive message structures sent by other processes and store the message structures in the message receiving queue of the process.

[0031] This specification provides an inter-process communication device, the device comprising:

[0032] The first communication preparation module is used to establish a process list for any process; create a receiving message queue corresponding to the process; and expand the receiving message queue to the process list of the process; wherein the process list is generated based on the process information of the target device;

[0033] The first communication execution module is used to generate a message structure according to the task to be executed by the target process when the process needs to communicate with the target process, and send the message structure to the receiving message queue corresponding to the target process so that the target process can execute the task according to the receiving message queue.

[0034] The target process executing the task according to the received message queue includes:

[0035] The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data.

[0036] This specification provides another inter-process communication device, the device comprising:

[0037] The second communication preparation module is used to establish a process list for any process; create a receiving message queue corresponding to the process, and expand the receiving message queue to the process list of the process; wherein the receiving message queue is used to arrange message structures sent by other processes; wherein the process list is generated based on the process information of the target device;

[0038] The second communication execution module is used to determine the message structure to be processed based on the received message queue, determine the target operation to be performed based on the message structure to be processed, determine the data to be operated on from the shared memory, and perform the target operation on the data.

[0039] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0040] This embodiment of the specification abandons data structures in the kernel and uses shared memory in user space. This eliminates the need for frequent data read / write operations between user and kernel modes, reducing CPU resource consumption and improving the efficiency of inter-process communication. Furthermore, this embodiment uses a message queue to manipulate shared memory, making operations on shared memory atomic and ensuring that only one process can read and write data in shared memory at a time, thus guaranteeing data accuracy. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments of this specification or the prior art will be briefly described below. Obviously, the drawings used in some embodiments of this application are only described below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating the inter-process communication method provided in the first embodiment of this specification.

[0043] Figure 2 This is a schematic diagram of the inter-process communication process in the first embodiment of this specification.

[0044] Figure 3 This is a schematic diagram of the message structure in the first embodiment of this specification.

[0045] Figure 4 This is a flowchart illustrating the inter-process communication method provided in the second embodiment of this specification.

[0046] Figure 5 This is a schematic diagram of the inter-process communication device provided in the third embodiment of this specification.

[0047] Figure 6 This is a schematic diagram of the inter-process communication device provided in the fourth embodiment of this specification. Detailed Implementation

[0048] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments involved in the specific implementation are only a part of the embodiments of this application, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments in the specific implementation without creative effort should fall within the protection scope of this application.

[0049] The first embodiment of this specification (hereinafter referred to as "Embodiment 1") provides an inter-process communication method. The execution subject of Embodiment 1 includes, but is not limited to, a terminal, a server, an operating system, or an application. That is, the execution subject can be diverse and can be set, used, or changed as needed. Alternatively, a third-party application can assist the execution subject in executing Embodiment 1. For example, a server can execute the data processing method in Embodiment 1, and a corresponding application can be installed on a terminal (which may be held by a user). Data transmission can occur between the terminal or the application and the server, thereby assisting the server in executing the data processing method in Embodiment 1.

[0050] refer to Figure 1 and Figure 2 The inter-process communication method provided in Implementation Example 1 includes:

[0051] S101: For any process, create a process list for that process; wherein the process list is generated based on the process information of the target device;

[0052] After the target device (including but not limited to embedded communication devices) boots up, each process begins to run. The following description is from the perspective of a single process:

[0053] For any given process, a process list can be created within that process. This process list is generated based on the process information of the target device.

[0054] Specifically, it can obtain process information of the target device, including a process table containing all processes, process IDs of each process, and other global resource information. Based on the process table, a table composed of the process IDs of each process is stored; this table is the process list. The specific format of the process list is not limited, but its main information includes each process and its process ID.

[0055] By copying the process list into each process, it is possible to create a process list within any given process. This list can then be executed by the first process started by the target device.

[0056] S103: Create a message queue corresponding to the process, and extend the message queue to the process list of the process;

[0057] In Example 1, for any process, a message receiving queue corresponding to that process is created, and the message receiving queue is expanded into the process list of that process. The message receiving queue can have multiple positions or spaces, which form a queue-like structure. Of course, the specific structure of the message receiving queue is not limited.

[0058] The message queue corresponding to this process is bound to the process ID of that process. For this process, a process list has already been established, and since the message queue corresponding to this process is bound to its process ID, the message queue of this process is extended to the process list of this process (through the process ID).

[0059] After the message queue is expanded, the process list of the process exists independently, is maintained by the process itself, and is visible to each process.

[0060] In addition, the message receiving queue of this process can be assigned a queue identifier, and different processes have different identifiers for their respective message receiving queues. Before the message receiving queue is actually used to receive various types of messages, some preprocessing operations can be performed on the message receiving queue, such as initializing the message receiving queue. These preprocessing operations can be performed as needed, and are not limited in Example 1.

[0061] In Example 1, for any process, a corresponding thread can be started. This thread is used to receive various types of messages sent by other processes and store the received messages in the process's message queue. Hereinafter, this thread will be referred to as the message receiving thread.

[0062] For any given process, it can be linked to shared memory that is visible to all processes. Specifically, after the target device starts, a process (such as the first process started by the target device mentioned above) can obtain the target device's heap, stack space, registers, and other internal resources, and then determine the shared memory that is shared by all processes. Each process can then link to this shared memory after it starts.

[0063] The above-mentioned tasks, including expanding the message queue and process list, preprocessing operations for the message queue, starting the message receiving thread, and linking processes to shared memory, can be considered as preparatory work for inter-process communication. In practical scenarios, these preparatory tasks can be applied as needed to perform inter-process communication.

[0064] S105: When the process needs to communicate with the target process, it generates a message structure according to the task to be executed by the target process, and sends the message structure to the receiving message queue corresponding to the target process, so that the target process can execute the task according to the receiving message queue; wherein, the target process executing the task according to the receiving message queue includes: determining the message structure to be processed according to the receiving message queue, determining the target operation to be executed according to the message structure to be processed, and determining the data to be operated on from the shared memory, and performing the target operation on the data.

[0065] For any given process, when it needs to communicate with a target process (the process that the process wants to communicate with or send messages to), and when sending messages to other processes, it can generate a message structure based on the tasks that the target process needs to perform. The tasks that the target process needs to perform specify which data and what operations the target process needs to perform (hereinafter referred to as the target operations).

[0066] Before generating the message structure, the sending process can prepare the data that the target process needs to process, request shared memory, and put the data that the target process needs to process into the shared memory.

[0067] A message structure may include a message header and a message body. The content of the message header includes, but is not limited to:

[0068] (1) The ID of the receiving process (i.e., the target process);

[0069] (2) The ID of the sending process (i.e., the process that sends the message structure, which is any of the above processes);

[0070] (3) The length of the IPC message;

[0071] (4) The number of IPC messages;

[0072] (5) IPC message types;

[0073] (6) IPC message subtypes;

[0074] (7) IPC message opcode (representing the target operation that the receiving process wants to perform on the data);

[0075] (8) Priority.

[0076] The message body contains, but is not limited to, the location information of the data that the target process needs to process in shared memory, so that the target process can locate this data in shared memory based on the message body. For example, data that needs to be processed by the target process is copied into shared memory, and an offset data address value is parsed and included in the message body. The data in shared memory can be located using the offset data address value.

[0077] For details on the message header and message body, please refer to... Figure 3 . Figure 3 This is just an example; in practice, the content or format of the message header or message body can be set or changed as needed.

[0078] In Example 1, the sending process assembles the message header and message body into a message structure and sends the message structure to the receiving message queue corresponding to the target process, so that the target process can execute the "task that needs to be executed by the target process" according to the receiving message queue.

[0079] Furthermore, in practice, the sending interface of the message structure and the receiving interface of the target process can be determined according to different needs. For example, the sending process can determine the sending interface of the message structure and the receiving interface of the target process based on whether the target process needs to return an acknowledgment message. The corresponding functionality can be implemented based on the different sending and receiving interfaces called and the different input parameters.

[0080] For example, to achieve synchronization (i.e., synchronization between the sending and receiving processes), the sending process calls the `reply` method. The sending process needs to wait for a response from the receiving process, and can therefore select the appropriate sending and receiving interfaces. Alternatively, to achieve asynchronous functionality, the sending process calls a non-`reply` method. The sending process is considered to be sending a notification to the receiving process and does not need a response from the receiving process; in this case, it can select the appropriate sending and receiving interfaces. Alternatively, after each message structure is sent, it can be determined whether the message structure has reached the target process's receiving message queue within a specified time. If not, the sending process resends the message structure to the target process's receiving message queue, and this resending can be repeated multiple times until the message structure is sent to the receiving process's receiving message queue within the specified time. Specifically, the specified time can be reflected by the sending process's `timeout` parameter. In this way, the `timeout` parameter is used to implement a timeout retransmission mechanism, reducing the impact of accidental factors (such as device lag) on ​​the communication result.

[0081] The following explains from the perspective of the target thread how to receive a message structure and execute the task according to the received message queue:

[0082] As mentioned earlier, the receive message queue can receive various types of messages, each of which includes a message structure. The receive message queue is used to arrange message structures sent by other processes.

[0083] The message structure sent by the sending process is received by the message receiving thread of the target process, and a corresponding sequence identifier is assigned to the message structure. The sequence identifier can be a sequence number, serial number, or other form used to indicate the order or sequence number of the message structure.

[0084] On one hand, upon receiving a new message structure, the system checks the maximum sequence identifier of message structures that the current target process has not yet processed, and then assigns the next sequence identifier to the newly received message structure. For example, if the maximum sequence identifier of message structures that the current target process has not yet processed is p, then the sequence identifier of the newly received message structure is p+1. On the other hand, the target process determines the message structure to be processed based on its corresponding message queue. Specifically, when the target process processes a message structure, the message structure corresponding to the first sequence identifier in the message queue is the message structure to be processed. Assuming message structure A is the message structure to be processed, when message structure A is processed, the sequence identifier corresponding to message structure A in the message queue will be released, and the message structure corresponding to the next sequence identifier will advance and be updated to the just-released sequence identifier.

[0085] In summary, the message structure processed by the target process is always the message structure corresponding to the first sequence identifier in the target process's receive message queue. This is because, after the target device starts up, the first message structure received by the target process is assigned to the first sequence identifier in the target process's receive message queue (assuming the sequence identifier is in numerical form, the first sequence identifier is 1), and the target process will process the message structure with sequence identifier 1. When receiving the next message structure, the following cases apply:

[0086] In case 1, if the message structure with sequence identifier 1 has been processed, then sequence identifier 1 has been released, and the next message structure received will still be assigned sequence identifier 1 and processed by the target process.

[0087] In scenario two, if the message structure with sequence identifier 1 has not yet been processed, the sequence identifier of the next received message structure will be 2. Once the message structure with sequence identifier 1 has been processed, sequence identifier 1 is released, and the original message structure with sequence identifier 2 moves up one position, meaning its sequence identifier is updated to 1, and it is then processed by the target process.

[0088] Following this pattern, the target process initially treats the message structure corresponding to the first-order identifier in the currently received message queue as the message structure to be processed. Upon receiving a new message structure, it checks the largest order identifier of the message structures that the target process has not yet finished processing, and then assigns the next order identifier to the newly received message structure. Each time the target thread finishes processing a message structure, it updates the received message queue and iterates through the updated queue, continuing to treat the message structure corresponding to the first-order identifier in the updated queue as the message structure to be processed. Specifically, updating the received message queue after processing a message structure means updating the order identifiers of all currently pending message structures (i.e., advancing the order identifiers of all currently pending message structures by one position).

[0089] This process repeats itself, with the target process determining the message structure to be processed based on the received message queue, and ensuring that the target process always processes the message structure corresponding to the first sequential identifier in the received message queue.

[0090] The following explains how the target thread processes the message structure and how it executes tasks:

[0091] The target thread determines the target operation to be performed based on the message structure it needs to process, and also determines the data to be manipulated from shared memory. Specifically, the target process parses the message structure to obtain the message header and message body. Based on the message header, the target process can determine the target operation to be performed (see the explanation of the message header above). Figure 3 The target process can locate the data to be operated on from the shared memory based on the message body, and then perform the target operation on the located data, that is, perform the task that the target process needs to perform.

[0092] In Example 1, the target process determines whether to return a response message to the process that sent the message structure based on the sending interface used by the process that sent the message structure.

[0093] If a response message is required, the target process generates a message structure based on the required response message and sends the message structure to the corresponding process for processing. The specifics have been explained above and will not be repeated here.

[0094] It should be noted that if the target process is only sending response messages to other processes, then generally, the target process does not need to store data in shared memory. Instead, it only needs to generate a message structure according to the response message returned, and send the message structure to the corresponding process, which will then process the message structure.

[0095] In Example 1, shared memory allows only a single process to read and write data at a time. When a process is processing a message structure and reading or writing data in shared memory, other processes that need to read or write data in shared memory can wait. After the current process finishes reading or writing data, the next process can then read or write data in shared memory. Specifically, the sending and receiving processes can also have a specific order, which can be determined based on the time when they request to write data to shared memory (sending process) and the time when they request to read data from shared memory (receiving process).

[0096] The following specific examples further illustrate Embodiment 1:

[0097] Assuming the sending process is an alarm process and the target process is a terminal process, the alarm process will execute the following:

[0098] Data preparation: The alarm process prepares the data that the terminal process needs to process and assembles the data into a structure.

[0099] Request shared memory and fill it with data: The alarm process requests a space in the shared memory it is linked to, copies the data that the terminal process needs to process into that space, and resolves an offset data address value.

[0100] Assemble the message structure: Generate a message structure according to the task to be executed by the terminal process. The message structure includes a message header and a message body. The message header indicates that the receiving process is the terminal process, the sending process is the alarm process, the data length, quantity, type, and subtype are determined by the data already placed in shared memory, the opcode is selected as needed (for example, the EVENT event notification flag can be used in this example), and the corresponding priority is selected according to the importance of the event. The message body records the offset data address value.

[0101] Select API on demand: You can determine the sending interface of the message structure and the receiving interface of the terminal process based on whether the terminal process needs to return an acknowledgment message.

[0102] Send message structure: Sends the message structure to the terminal process's receive message queue, waiting for the terminal process to process the message structure.

[0103] The terminal process executes the following:

[0104] Waiting to receive a message;

[0105] Discover and receive the message structure, and assign a sequence identifier;

[0106] Iterate through its own message queue and process the message structure that is first in the order.

[0107] As mentioned earlier, after the message structure sent by the alarm process is received, it is assigned a sequence identifier. However, it may not be the first message structure in the current sequence, so it needs to wait for the receiving process to process it. It is possible that after a certain update to the received message queue, the message structure sent by the alarm process will become the first message structure in the sequence and will be processed by the terminal process.

[0108] The specific processing steps include: the terminal process parses the message structure to obtain the message header and message body, including information such as the sending process ID, length, quantity, type, subtype, opcode, and priority in the message header, as well as the address offset information in the message body. Specifically, the sending process ID identifies the message structure as being sent by the alarm process, and the opcode indicates that an EVENT operation (i.e., the target operation) needs to be performed on the data.

[0109] The pointer in the message body points to shared memory, and the offset in the message body maps to a specified region in memory. Correspondingly, the terminal process can use the offset data address value in the message body and the shared memory address to demap a piece of data from the shared memory, that is, the data that the alarm process packaged and put into the shared memory for the terminal process to process.

[0110] The receiving process performs the target operation on the data demapped from the shared memory, releases the shared memory, and decides whether to return an acknowledgment message to the sending process based on the sending API used by the alarm process.

[0111] Example 1 can achieve the following beneficial effects:

[0112] In existing inter-process communication using message queues, the queue is essentially a linked list data structure provided by the kernel. Writing data to the message queue is essentially inserting a new node into this data structure; reading data from the message queue is essentially retrieving and deleting a node from this data structure. During communication, the sending process defines the message to be sent in its own message buffer and then links the message structure to the linked list in the kernel. The receiving process matches the corresponding node from the linked list (i.e., the message queue) in the kernel, retrieves the message, stores it in the receiving process's message buffer, and then deletes the node. This process involves frequent data copying between user space and kernel space, and the frequent read and write operations in kernel space consume additional CPU resources.

[0113] In Implementation Example 1, the data structures in the kernel are discarded and shared memory in user space is used instead. This eliminates the need for frequent data read and write operations between user space and kernel space, reducing CPU resource consumption and thus improving the efficiency of inter-process communication.

[0114] Existing inter-process communication methods implemented through shared memory lack synchronization and mutual exclusion mechanisms. Therefore, when multiple processes operate on shared memory simultaneously, there is no mechanism to prevent another process from reading or writing to the shared memory before process one finishes reading or writing to it.

[0115] In Implementation Example 1, the method of using a message queue to manipulate shared memory makes the operation on shared memory atomic, ensuring that only one process can read and write the data in shared memory at a time, thus ensuring data accuracy and improving the inter-process communication effect.

[0116] Through Example 1, data interaction can ensure synchronization when using shared memory by leveraging the characteristics of the message queue, thus guaranteeing data correctness. Furthermore, the shared memory approach eliminates the need for kernel-mode operations, reducing the consumption of CPU, memory, and other resources, and improving the efficiency of inter-process communication in embedded systems.

[0117] Example 1 can stably and efficiently meet the inter-process communication requirements, and is easy to maintain and less prone to errors.

[0118] Example 1 implements the use of synchronous and asynchronous functions on demand during communication, adds a timeout retransmission mechanism during communication, and improves the efficiency and accuracy of inter-process communication.

[0119] The second embodiment of this specification (hereinafter referred to as "Embodiment Two") provides an inter-process communication method. The execution subject of Embodiment Two includes, but is not limited to, a terminal, a server, an operating system, or an application. That is, the execution subject can be diverse and can be set, used, or changed as needed. Additionally, a third-party application can assist the execution subject in executing Embodiment Two. For example, a server can execute the data processing method in Embodiment Two, and a corresponding application can be installed on a terminal (which may be held by a user). Data transmission can occur between the terminal or application and the server, thereby assisting the server in executing the data processing method in Embodiment Two.

[0120] refer to Figure 4 The inter-process communication method provided in Example 2 includes:

[0121] S202: For any process, create a process list for that process; wherein the process list is generated based on the process information of the target device;

[0122] See Example 1 for details.

[0123] S204: Create a message queue corresponding to the process and expand the message queue to the process list of the process; wherein the message queue is used to arrange message structures sent by other processes;

[0124] See Example 1 for details.

[0125] S206: Determine the message structure to be processed based on the received message queue, determine the target operation to be performed based on the message structure to be processed, and determine the data to be operated on from the shared memory, and perform the target operation on the data.

[0126] See Example 1 for details.

[0127] In Example 2, after receiving a message structure, the system checks the maximum sequence identifier of the currently unprocessed message structures and then assigns the next sequence identifier to the newly received message structure. See Example 1 for details.

[0128] In Example 2, determining the message structure to be processed based on the received message queue may include:

[0129] The message structure corresponding to the first sorted identifier in the current received message queue is taken as the message structure to be processed.

[0130] After processing each message structure, update the received message queue, and continue to use the message structure corresponding to the first sorted message structure in the updated received message queue as the message structure to be processed.

[0131] See Example 1 for details.

[0132] In Example 2, for any process, a message receiving thread corresponding to that process is started. This message receiving thread is used to receive message structures sent by other processes and store the message structures in the process's message receiving queue. See Example 1 for details.

[0133] For any details not described in Example 2, please refer to Example 1 for implementation.

[0134] Since a single process can be either a sending process or a receiving process, the executing entity of Embodiment 1 or Embodiment 2 can be either a single process or a target device.

[0135] The third embodiment of this specification provides an inter-process communication device corresponding to the inter-process communication method described in Embodiment 1. (See reference...) Figure 5 The inter-process communication device includes:

[0136] The first communication preparation module 301 is used to establish a process list for any process; create a receiving message queue corresponding to the process; and expand the receiving message queue to the process list of the process; wherein the process list is generated based on the process information of the target device;

[0137] The first communication execution module 303 is used to generate a message structure according to the task to be executed by the target process when the process needs to communicate with the target process, and send the message structure to the receiving message queue corresponding to the target process so that the target process can execute the task according to the receiving message queue.

[0138] The target process executing the task according to the received message queue includes:

[0139] The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data.

[0140] Optionally, the first communication preparation module 301 is further configured to link the process to a shared memory shared by all processes before generating a message structure according to the task to be executed by the target process.

[0141] Optionally, the first communication preparation module 301 is further configured to place the data that the target process needs to process into shared memory before sending the message structure to the receiving message queue corresponding to the target process, wherein the message structure includes the location information of the data in the shared memory.

[0142] Optionally, the first communication execution module 303 is further configured to:

[0143] The sending interface of the message structure is determined based on whether the target process needs to return a response message.

[0144] And / or,

[0145] Determine whether the message structure has arrived at the message receiving queue corresponding to the target process within the agreed time;

[0146] If not, the message structure is resent to the message queue corresponding to the target process.

[0147] The fourth embodiment of this specification provides an inter-process communication device corresponding to the inter-process communication method described in Embodiment 2. (See reference...) Figure 6 The inter-process communication device includes:

[0148] The second communication preparation module 402 is used to establish a process list for any process; create a receiving message queue corresponding to the process, and expand the receiving message queue to the process list of the process; wherein the receiving message queue is used to arrange message structures sent by other processes; wherein the process list is generated based on the process information of the target device;

[0149] The second communication execution module 404 is used to determine the message structure to be processed according to the received message queue, determine the target operation to be performed according to the message structure to be processed, and determine the data to be operated on from the shared memory, and perform the target operation on the data.

[0150] Optionally, the second communication execution module 404 is further configured to, after receiving the message structure, check the maximum sequence identifier of the message structure that has not yet been processed, and then assign the next sequence identifier to the newly received message structure.

[0151] Optionally, determining the message structure to be processed based on the received message queue includes:

[0152] The message structure corresponding to the first sorted identifier in the current received message queue is taken as the message structure to be processed.

[0153] After processing each message structure, update the received message queue, and continue to use the message structure corresponding to the first sorted message structure in the updated received message queue as the message structure to be processed.

[0154] Optionally, the second communication execution module 404 is further configured to start the message receiving thread corresponding to the process, wherein the message receiving thread is configured to receive message structures sent by other processes and store the message structures in the message receiving queue of the process.

[0155] The above embodiments can be used in conjunction with each other. Modules with the same name in different embodiments can be the same module or different modules.

[0156] The above description is merely an embodiment of this specification and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. An inter-process communication method, characterized in that, The method includes: For any given process, a process list is created for that process; wherein the process list is generated based on the process information of the target device; Create a receive message queue corresponding to the process, and expand the receive message queue to the process list of the process; When the process needs to communicate with the target process, it generates a message structure according to the task to be executed by the target process, and sends the message structure to the receiving message queue corresponding to the target process, so that the target process can execute the task according to the receiving message queue. The target process executing the task according to the received message queue includes: The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data. The shared memory allows only a single process to read and write data at a time; when a process is processing a message structure and reading or writing data in the shared memory, other processes that need to read or write data in the shared memory must wait; after the current process has finished reading or writing data, the next process can then read or write data in the shared memory. The method further includes: The sending process determines the sending interface for the message structure and the receiving interface for the target process based on whether a response message is required from the target process. Depending on the called sending and receiving interfaces and the input parameters, the corresponding function is implemented. Specifically, if the sending process calls the `reply` method to achieve synchronous functionality, it needs to wait for a response from the receiving process and selects the appropriate sending and receiving interfaces. Alternatively, if the sending process calls a non-`reply` method to achieve asynchronous functionality, it considers it as sending a notification to the receiving process and does not require a response, and selects the appropriate sending and receiving interfaces. Alternatively, after each message structure is sent, it determines whether the message structure has reached the target process's receiving message queue within a specified time. If not, the sending process resends the message structure to the target process's receiving message queue, and this resending can be repeated multiple times until the message structure is sent to the receiving process's receiving message queue within the specified time. The sending process is the process that sends the message structure.

2. The method as described in claim 1, characterized in that, Before generating the message structure according to the task to be executed by the target process, the method further includes: Link the process to shared memory that is used by all processes.

3. The method as described in claim 1 or 2, characterized in that, Before sending the message structure to the receiving message queue corresponding to the target process, the method further includes: The data that the target process needs to process is placed in shared memory, and the message structure includes the location information of the data in the shared memory.

4. The method as described in claim 1, characterized in that, The method further includes: The sending interface of the message structure is determined based on whether the target process needs to return a response message. And / or, Determine whether the message structure has arrived at the message receiving queue corresponding to the target process within the agreed time; If not, the message structure is resent to the message queue corresponding to the target process.

5. An inter-process communication method, characterized in that, The method includes: For any given process, a process list is created for that process; wherein the process list is generated based on the process information of the target device; Create a message queue corresponding to the process, and expand the message queue to the process list of the process; wherein the message queue is used to arrange message structures sent by other processes; The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data. The shared memory allows only a single process to read and write data at a time; when a process is processing a message structure and reading or writing data in the shared memory, other processes that need to read or write data in the shared memory must wait; after the current process has finished reading or writing data, the next process can then read or write data in the shared memory. The method further includes: The sending process determines the sending interface for the message structure and the receiving interface for the target process based on whether a response message is required from the target process. Depending on the called sending and receiving interfaces and the input parameters, the corresponding function is implemented. Specifically, if the sending process calls the `reply` method to achieve synchronous functionality, it needs to wait for a response from the receiving process and selects the appropriate sending and receiving interfaces. Alternatively, if the sending process calls a non-`reply` method to achieve asynchronous functionality, it considers the sending process as sending a notification to the receiving process and does not require a response, and selects the appropriate sending and receiving interfaces. Alternatively, after each message structure is sent, it is determined whether the message structure has reached the target process's corresponding receiving message queue within a specified time. If not, the sending process resends the message structure to the target process's receiving message queue, and this resending can be repeated multiple times until the message structure is sent to the receiving process's receiving message queue within the specified time. The sending process is the process that sends the message structure, and the target process is the process that the sending process needs to communicate with or send messages to.

6. The method as described in claim 5, characterized in that, The method further includes: After receiving a message structure, check the maximum sequence identifier of the message structures that have not yet been processed, and then assign the next sequence identifier to the newly received message structure.

7. The method as described in claim 5 or 6, characterized in that, The message structure to be processed is determined based on the received message queue, including: The message structure corresponding to the first sorted identifier in the current received message queue is taken as the message structure to be processed. After processing each message structure, update the received message queue, and continue to use the message structure corresponding to the first sorted message structure in the updated received message queue as the message structure to be processed.

8. The method as described in claim 5, characterized in that, The method further includes: Start the message receiving thread corresponding to the process. The message receiving thread is used to receive message structures sent by other processes and store the message structures in the message receiving queue of the process.

9. An inter-process communication device, characterized in that, The device includes: The first communication preparation module is used to establish a process list for any process; create a receiving message queue corresponding to the process; and expand the receiving message queue to the process list of the process; wherein the process list is generated based on the process information of the target device; The first communication execution module is used to generate a message structure according to the task to be executed by the target process when the process needs to communicate with the target process, and send the message structure to the receiving message queue corresponding to the target process so that the target process can execute the task according to the receiving message queue. The target process executing the task according to the received message queue includes: The message structure to be processed is determined based on the received message queue, the target operation to be performed is determined based on the message structure to be processed, and the data to be operated on is determined from the shared memory, and the target operation is performed on the data. The shared memory allows only a single process to read and write data at a time; when a process is processing a message structure and reading or writing data in the shared memory, other processes that need to read or write data in the shared memory must wait; after the current process has finished reading or writing data, the next process can then read or write data in the shared memory. The sending process determines the sending interface for the message structure and the receiving interface for the target process based on whether a response message is required from the target process. Depending on the called sending and receiving interfaces and the input parameters, the corresponding function is implemented. Specifically, if the sending process calls the `reply` method to achieve synchronous functionality, it needs to wait for a response from the receiving process and selects the appropriate sending and receiving interfaces. Alternatively, if the sending process calls a non-`reply` method to achieve asynchronous functionality, it considers the sending process as sending a notification to the receiving process and does not require a response, and selects the appropriate sending and receiving interfaces. Alternatively, after each message structure is sent, it is determined whether the message structure has reached the target process's corresponding receiving message queue within a specified time. If not, the sending process resends the message structure to the target process's receiving message queue, and this resending can be repeated multiple times until the message structure is sent to the receiving process's receiving message queue within the specified time. The sending process is the process that sends the message structure, and the target process is the process that the sending process needs to communicate with or send messages to.

10. An inter-process communication device, characterized in that, The device includes: The second communication preparation module is used to establish a process list for any process; create a receiving message queue corresponding to the process, and expand the receiving message queue to the process list of the process; wherein the receiving message queue is used to arrange message structures sent by other processes; wherein the process list is generated based on the process information of the target device; The second communication execution module is used to determine the message structure to be processed based on the received message queue, determine the target operation to be performed based on the message structure to be processed, and determine the data to be operated on from the shared memory, and perform the target operation on the data. The shared memory allows only a single process to read and write data at a time; when a process is processing a message structure and reading or writing data in the shared memory, other processes that need to read or write data in the shared memory must wait; after the current process has finished reading or writing data, the next process can then read or write data in the shared memory. The sending process determines the sending interface for the message structure and the receiving interface for the target process based on whether a response message is required from the target process. Depending on the called sending and receiving interfaces and the input parameters, the corresponding function is implemented. Specifically, if the sending process calls the `reply` method to achieve synchronous functionality, it needs to wait for a response from the receiving process and selects the appropriate sending and receiving interfaces. Alternatively, if the sending process calls a non-`reply` method to achieve asynchronous functionality, it considers it as sending a notification to the receiving process and does not require a response, and selects the appropriate sending and receiving interfaces. Alternatively, after each message structure is sent, it determines whether the message structure has reached the target process's receiving message queue within a specified time. If not, the sending process resends the message structure to the target process's receiving message queue, and this resending can be repeated multiple times until the message structure is sent to the receiving process's receiving message queue within the specified time. The sending process is the process that sends the message structure.

Images