Distributed shared memory system based on udp and message processing method

Abstract

The embodiment of the application discloses a software distributed shared memory system based on UDP, which comprises N hosts, each host comprising: a communication manager, recording local host identification, remote host communication information, communication port information and message confirmation information; a message pool, comprising a plurality of reusable message slots; an output queue, buffering a to-be-sent message; an input queue, buffering a to-be-served message; a main thread, obtaining an idle message slot from the message pool, generating a to-be-sent message, and placing the to-be-sent message into the output queue; a sending thread, taking out the to-be-sent message from the output queue, and sending the to-be-sent message to a destination host through UDP; a listening thread execution module, listening to UDP messages from a remote host, sending a confirmation message to a message source host after receiving a normal message, and placing the received normal message into the input queue; and a service thread execution module, used for taking out a message from the input queue, and executing a corresponding software distributed shared memory service according to the message type.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a UDP-based distributed shared memory system and message processing method. Background Technology

[0002] As Moore's Law gradually loses its effectiveness, processor performance growth is slowing, and improvements in single-core performance are increasingly unable to support ever-more complex computing demands. As a result, people are increasingly turning their attention to or returning to parallel computing. Distributed shared memory systems, as a crucial technology in parallel computing, combine the scalability of distributed systems with the programming convenience of shared memory systems, providing a balanced solution for large-scale computing problems. Distributed shared memory systems can be implemented at the hardware, software, and language levels. Among these, software-implemented distributed shared memory systems (SDSM) offer advantages such as low cost, scalability, and platform and hardware independence. SDSM provides transparent API interfaces to users as a software library. Users do not need to understand the underlying communication details; they only need to call the corresponding interfaces to write applications that run on distributed systems, just like writing single-machine programs.

[0003] The design of the underlying communication scheme of SDSM typically affects the scalability of the entire system and the performance of programs running on it. These schemes usually include the design of communication data structures, communication port design, whether to use multithreading, and, when using multithreading, task partitioning and synchronization schemes for data contention between threads.

[0004] Existing SDSM systems have proposed various technical solutions for communication processing. Among them, the JIAJIA system employs a single-threaded communication model combined with signal-driven I / O, responding to network events by registering SIGIO signal handlers, and its communication ports use a "tiled" design of a two-dimensional array. The TreadMarks system also uses a single-threaded architecture, implemented as a user-level library, and runs on standard Unix systems. The CVM system supports multithreading, allowing overlap of computation and communication through context switching, but its multithreading support is primarily geared towards higher-level mechanisms such as thread migration and load balancing. The UCX communication acceleration library, as a high-performance communication framework, is used as a communication backend in various SDSM systems, but it uses TCP for inter-node communication on traditional Ethernet infrastructure.

[0005] The existing solutions mentioned above still have significant shortcomings in fully utilizing the parallel capabilities of multi-core processors. Single-threaded signal-driven I / O models face reentrancy issues in signal processing, the risk of signal queue overflow, and the inherent limitation of not being able to process multiple messages in parallel. TCP-based communication schemes introduce additional overhead such as message boundary marking and connection management. Therefore, there is an urgent need for an SDSM message processing scheme that can fully utilize the parallel capabilities of multi-core processors while maintaining low communication overhead. Summary of the Invention

[0006] In view of the above problems, embodiments of this application are proposed to provide a UDP-based distributed shared memory system and message processing method that overcomes or at least partially solves the above problems.

[0007] In a first aspect, embodiments of this application disclose a message processing method for a UDP-based distributed shared memory system. The distributed shared memory system comprises N hosts, each host running a software distributed shared memory system instance, where N is an integer greater than 1. The method, on each host, includes: Initialize the communication manager, message pool, input queue, and output queue. The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message acknowledgment information. The message pool includes multiple reusable message slots. Create a main thread, a sending thread, a listening thread, and at least one service thread; When the main thread detects a software distributed shared memory event, it obtains an idle message slot from the message pool, generates a message to be sent, and puts the message to be sent into the output queue. The sending thread retrieves the message to be sent from the output queue and sends the message to the destination host via UDP. The listening thread listens for UDP messages from a remote host, sends an acknowledgment message to the message source host upon receiving a normal message, and puts the received normal message into the input queue. The service thread retrieves messages from the input queue and executes the corresponding software distributed shared memory service according to the message type.

[0008] In other aspects, a UDP-based distributed shared memory system is disclosed, enabling the SDSM message service, which is triggered by unpredictable SIGIO signals and executed serially in a single-threaded context, to be restructured into a multi-threaded message processing pipeline connected by explicit queues. Simultaneously, the two-dimensional port relationship of "one set of ports per pair of hosts" is folded into a one-dimensional port naming rule of "base port + source host identifier / ACK critical port". Thus, on the one hand, time control is transferred from OS asynchronous signals to runtime thread scheduling: the listening thread is only responsible for receiving and preprocessing packets, the service thread is only responsible for serving SDSM semantics, the sending thread is only responsible for dequeuing, sending, ACKing, and retransmission, and the main thread is responsible for parallel program logic as much as possible. On the other hand, communication addressing is shifted from a "two-dimensional port table between hosts" to a linear rule of "host identifier encoded into port number". Attached Figure Description

[0009] Figure 1 This is an overall structural diagram of the software distributed shared memory system according to an embodiment of this application; Figure 2 This is the overall message processing framework of the embodiments of this application; Figure 3 This is a message processing structure diagram within a single host in an embodiment of this application; Figure 4 This is a schematic diagram of UDP port mapping according to an embodiment of this application; Figure 5 This is a schematic diagram of the communication data structure according to an embodiment of this application; Figure 6 This is a schematic diagram of communication task division according to an embodiment of this application; Figure 7 This is the communication port design of an embodiment of this application. Detailed Implementation

[0010] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0011] In existing technologies, JIAJIA employs a single-threaded design and a signal-driven I / O model for communication. This model registers a SIGIO signal handler using the `sigaction` system call during communication initialization. When a datagram on the corresponding socket descriptor is ready to be read, the kernel sends a SIGIO signal to the process, and the user triggers the signal handler upon receiving the signal. However, due to the unpredictable nature of SIGIO signal occurrences, this signal-driven I / O model suffers from the following problems in practical applications: the signal may be triggered at any time during program execution, interrupting the current program execution. Therefore, it is necessary to ensure that the signal handler logic is reentrant and thread-safe, which involves setting signal disabling and enabling in critical sections, introducing a large amount of signal masking and unmasking code; moreover, a large number of SIGIO signals may fill the signal queue, leading to the loss of subsequent signals; furthermore, when multiple signals trigger the signal handler simultaneously, the single-threaded design means that the signal handlers can only be executed sequentially, failing to fully utilize the parallel computing capabilities of the underlying hardware.

[0012] In terms of communication port design, JIAJIA employs a "tiled" port design, which includes two two-dimensional port arrays: a request port array (req) and a response port array (rep). When machine A communicates with machine B, A uses req[A][B] to send a request to B and uses rep[A][B] to send a response. This design results in a port usage of N^2 level.

[0013] This application aims to provide a complete communication module design scheme for achieving high-performance message processing of UDP-based SDSM (Distributed Shared Memory System) on a distributed cluster composed of multi-core processors. This scheme focuses on fully utilizing the parallel processing capabilities of multi-core processors and proposes a comprehensive design strategy for the SDSM system's communication data structure, communication task partitioning, communication port design, and inter-thread synchronization mechanisms.

[0014] The communication data structure adopts a "one pool, one manager, two queues" design. The pool refers to the message pool, which is used to prepare empty message slots in advance. When the program needs to use the message, it can directly select an empty slot from the pool. This avoids the time overhead caused by frequently allocating / releasing memory.

[0015] The communication manager is responsible for recording interaction information with other hosts (such as communication sequences and communication endpoint descriptors). The two queues refer to the input queue and the output queue, respectively, and are used to hold messages that will be processed differently.

[0016] Communication task design refers to dividing system participants into main threads, sending threads, listening threads, and service threads. The main thread is responsible for ensuring the correctness of the program logic running on the system, the sending thread is responsible for retrieving messages from the output queue and sending them, the listening thread is responsible for listening for messages from remote hosts and putting them into the input queue, and the service thread is responsible for retrieving messages from the input queue and executing the corresponding services.

[0017] Communication port design, when using UDP for network communication, involves using a random port for sending, a port determined by the message source host for receiving, and a threshold value for the ACK receiving port. Inter-thread synchronization design refers to using atomic variables and other measures to ensure correct program execution due to data contention between the main thread and the service thread.

[0018] Through the above strategies, the SDSM message service, which was originally triggered by unpredictable SIGIO signals and executed serially in a single-threaded context, has been reconstructed into a multi-threaded message processing pipeline connected by explicit queues. At the same time, the two-dimensional port relationship of "one set of ports per pair of hosts" has been folded into a one-dimensional port naming rule of "base port + source host identifier / ACK critical port".

[0019] Thus, on the one hand, time control shifts from asynchronous OS signals to runtime thread scheduling: the listening thread is only responsible for receiving and preprocessing packets, the service thread is only responsible for serving SDSM semantics, the sending thread is only responsible for dequeueing, sending, ACKing, and retransmission, and the main thread is responsible for parallel program logic as much as possible. On the other hand, communication addressing shifts from a "two-dimensional port table between hosts" to a linear rule of "host identifier encoding to port number".

[0020] Figure 1 The overall structure of the software distributed shared memory system provided in the embodiments of this application is shown. For example... Figure 1 As shown, the software distributed shared memory system comprises N hosts, where N is an integer greater than 1. The N hosts can be host 0, host 1, ..., host N-1. Each host runs a software distributed shared memory system instance, i.e., an SDSM instance. The SDSM instances on each host communicate with each other via a UDP network to achieve distributed management and access to shared memory.

[0021] Each SDSM instance on a host can generate a corresponding UDP message when it detects a software distributed shared memory event. Software distributed shared memory events can include at least one of the following: page fault request, page grant request, lock request, lock release, barrier request, barrier grant, or broadcast request. The generated UDP message is sent to the SDSM instance on the target host via the UDP network. Upon receiving the message, the SDSM instance on the target host executes the corresponding software distributed shared memory service based on the message type.

[0022] Figure 2 This paper demonstrates the overall system framework of this application, where both the message pool and input / output queues are runtime-adjustable data structures. This design can meet the communication needs of different types of applications as much as possible. The main thread sends messages to the output queue only when necessary (such as page faults / broadcasts / lock requests / lock releases). After sending a message, the work of interacting with the remote end is managed by other threads. The client thread is responsible for sending messages to the destination host. Before sending a message, the client thread can perform certain processing such as compression and encryption to reduce the leakage of important messages and the amount of messages transmitted. After sending, it can take measures such as confirmation mechanism and timeout retransmission to ensure that the remote end receives the corresponding message. The listener thread can listen for messages from multiple remote machines. After receiving a message, it can perform certain processing operations before enqueuing it, such as decryption, decompression, sorting, filtering, etc. After processing, the message is put into the input queue. The server thread can be designed as a unified thread that can serve all messages, or it can be a further subdivided dedicated thread that serves specific messages.

[0023] Figure 3 This illustrates a message processing structure within a single host provided in an embodiment of this application. For example... Figure 3 As shown, each host's SDSM instance includes a communication manager, message pool, output queue, input queue, main thread, sending thread, listening thread, service thread pool, and a pending message table. The service thread pool comprises one or more service threads.

[0024] The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message acknowledgment information. Furthermore, the communication manager can also record the mapping between the remote host address, the remote host identifier and the communication port, the sent message sequence number, the input queue status, the output queue status, the message pool status, and the acknowledgment status in the pending message table.

[0025] The message pool comprises multiple reusable message slots. Each message slot may include a message status field, a message type field, a source host identifier field, a destination host identifier field, a message sequence number field, and a message payload field. The message status field indicates whether the corresponding message slot is in one of the following states: idle, under construction, awaiting delivery, sending, awaiting acknowledgment, awaiting service, in service, or completed. When a message slot flows between the main thread, the sending thread, the listening thread, and the service thread, the message status field can be modified atomically to ensure that the same message slot is occupied by only one thread at a time.

[0026] The output queue is used to buffer messages to be sent. When the main thread detects a software distributed shared memory event, it obtains an idle message slot from the message pool, generates a message to be sent in that slot, and places the corresponding message into the output queue. The sending thread retrieves the message to be sent from the output queue and sends it to the destination host via the UDP communication port. For messages requiring acknowledgment, the sending thread registers the message in the pending acknowledgment table after sending; upon receiving the corresponding acknowledgment message, it marks the message as acknowledged; if no acknowledgment message is received within a preset timeout period, the message is resent.

[0027] The listener thread is used to monitor UDP messages from remote hosts. When the listener thread receives a normal message, it sends an acknowledgment message to the source host and places the received normal message into the input queue. When the listener thread receives an acknowledgment message, it can determine the corresponding message in the message to be acknowledged table based on at least one of the message sequence number, source host identifier, and destination host identifier in the acknowledgment message, and update the acknowledgment status of that message.

[0028] The input queue is used to cache messages awaiting service. One or more service threads in the service thread pool retrieve messages from the input queue and execute the corresponding software distributed shared memory service based on the message type. Multiple service threads can retrieve different messages from the input queue in parallel. When service threads process messages involving the same shared page, the same lock object, or the same barrier object, the corresponding critical sections are protected using atomic variables or locks. When a service thread processes a message involving writing data to a shared memory area accessible to the main thread or modifying the shared memory state, the service thread synchronizes with the main thread using atomic variables, locks, or wait conditions to prevent the main thread from accessing shared memory data or state that has not yet been updated.

[0029] Figure 4 This illustrates a UDP port mapping method provided in an embodiment of this application. For example... Figure 4 As shown, a software distributed shared memory system consists of N hosts, identified as 0 to N-1, with port B as the base port. Each host is configured with a sending port, multiple ordinary message receiving ports, and an acknowledgment message receiving port.

[0030] The sending port is a randomly available port. Figure 4 In this context, the sending port of the sending host i is denoted as Ai. This sending port can be a randomly available port assigned by the operating system and is used to send ordinary messages or acknowledgment messages to other hosts.

[0031] Each host has multiple ordinary message receiving ports, each corresponding to a different message source host identifier. For example, the ordinary message receiving port for receiving ordinary messages from host 0 is B+0, the ordinary message receiving port for receiving ordinary messages from host 1 is B+1, ..., the ordinary message receiving port for receiving ordinary messages from host i is B+i, and the ordinary message receiving port for receiving ordinary messages from host N-1 is B+N-1. The receiving host can determine or verify the message source host of an ordinary message based on the ordinary message receiving port of the received ordinary message.

[0032] Each host also has an acknowledgment message receiving port, designated B+N, used to receive acknowledgment messages from other hosts. When sending host i sends a normal message to receiving host j, sending host i transmits the normal message to the normal message receiving port B+i on receiving host j, which corresponds to the host identifier of sending host i, via a randomly available sending port Ai. After receiving the normal message, receiving host j sends an acknowledgment message to the acknowledgment message receiving port B+N of sending host i. This acknowledgment message may include at least one of the message sequence number of the message being acknowledged, the source host identifier, and the destination host identifier, so that sending host i can determine the corresponding message in the message to be acknowledged table.

[0033] Communication data structure design Figure 5 The diagram illustrates a communication data structure for a UDP-based software distributed shared memory system in an embodiment of this application. This communication data structure is designed around a "one pool, one manager, two queues" architecture, where "one pool" refers to a message pool, "one manager" refers to a communication manager, and "two queues" refer to an output queue and an input queue. Furthermore, to support UDP message acknowledgment and retransmission, a pending acknowledgment message table is also provided; to support message routing, matching, and verification, each message includes a fixed-format message header.

[0034] like Figure 5As shown, the communication manager is used to centrally store system-level communication information. The communication manager can include the local host identifier, the total number of hosts N, the base port B, the sending port, the acknowledgment message receiving port, the remote host table, the sequence number generator, and global statistics. Specifically, the local host identifier identifies the current host's number in the software distributed shared memory system; the total number of hosts determines the system size; the base port calculates the normal message receiving port and the acknowledgment message receiving port; the sending port can be a randomly available port; the acknowledgment message receiving port can be B+N; the remote host table records the remote host identifier, IP address, remote sending port, and remote normal message receiving port; the sequence number generator generates message sequence numbers for messages to be sent; and the global statistics record the number of transmissions, receptions, retransmissions, and other operational statuses.

[0035] The message pool (MsgPool) consists of a fixed number of message slots (MsgSlots). Each message slot stores the complete data of a message and its metadata. By pre-allocating multiple message slots, frequent dynamic memory allocation and deallocation between the main thread, sending thread, listening thread, and service thread can be avoided, thus reducing runtime overhead. Message slots can be referenced by slot indices, which are integers between 0 and M-1, where M is the number of message slots in the message pool.

[0036] Each message slot may include fields such as slot index, message status, message type, source host identifier, destination host identifier, message sequence number, payload length, message load, timestamp, and reference count. The message status field identifies the lifecycle state of the message slot, such as idle, under construction, pending transmission, sending, awaiting acknowledgment, awaiting service, in service, or completed. The message type field indicates the software distributed shared memory service type corresponding to the message. The source host identifier and destination host identifier are used for message routing and verification. The message sequence number is used to confirm message matching, deduplication, and retransmission control. The payload length and message load are used to store specific business data. The timestamp can be used for timeout detection, and the reference count can be used to determine whether the message slot can be released or reused.

[0037] The output queue is a circular queue used to store the message slot indexes of messages to be sent. After the main thread or service thread generates a message to be sent, it writes the slot index of the corresponding message slot into the output queue. The sending thread retrieves the slot index from the output queue and accesses the corresponding message slot in the message pool according to the slot index, thereby sending the corresponding message. The output queue can implement lock-free enqueueing and dequeueing through two atomic indexes, head and tail, thus supporting scenarios with multiple producers and a single consumer or multiple producers and multiple consumers.

[0038] The input queue can also be a circular queue, used to store the message slot indexes of messages to be served. When a listening thread receives a normal message, it retrieves an idle message slot from the message pool, writes the received message into that slot, and writes the slot index into the input queue. The service thread retrieves the slot index from the input queue, accesses the corresponding message slot in the message pool based on the slot index, and executes the corresponding software distributed shared memory service. The input queue can also achieve lock-free enqueueing and dequeueing using two atomic indexes, head and tail.

[0039] The PendingAckTable records messages that have been sent and require acknowledgment. The PendingAckTable can be a hash table, where the key is the message sequence number (seq_no_i) and the values ​​are the tracking information for the message to be acknowledged. This tracking information may include the message slot index, destination host identifier, sending time, number of retransmissions, and acknowledgment flag. After sending a message requiring acknowledgment, the sending thread registers the message in the PendingAckTable. Upon receiving an acknowledgment message, the listening thread looks up the PendingAckTable based on the message sequence number in the acknowledgment message and marks the corresponding message as acknowledged. If a message is not acknowledged within a preset timeout period, the sending thread can resend the corresponding message based on the message slot index in the table.

[0040] The message header, located at the beginning of the message payload, carries fixed fields required for message routing, matching, and integrity verification. The message header may include a magic number, version number, message type, source host identifier, destination host identifier, message sequence number, payload length, flags, reserved fields, and a checksum. The magic number identifies the message format; the version number distinguishes the protocol version; the message type indicates the message's purpose; the source and destination host identifiers determine the message's source and destination; the message sequence number confirms matching and deduplication; the payload length determines the length of subsequent payload data; flags indicate whether acknowledgment is required, whether it's a retransmission, or a response message; reserved fields are used for later expansion; and the checksum detects errors in the message header or the message as a whole.

[0041] Through the aforementioned communication data structure, the main thread, sending thread, listening thread, and service thread do not directly pass complete message copies; instead, they primarily pass message references through message slot indexes. This reduces message copying overhead and facilitates unified management of the message lifecycle through message status fields. Furthermore, the communication manager, message pool, input queue, output queue, and pending message table work together to enable this application to support the parallel execution of message generation, sending, receiving, acknowledgment, timeout retransmission, and service processing.

[0042] Communication task division In this embodiment, to fully utilize the multi-core processing power of a single host, the communication tasks in the UDP-based software distributed shared memory system are divided into main thread tasks, sending thread tasks, listening thread tasks, and service thread tasks. This task division allows the message processing process, originally executed serially by a single thread, to be broken down into multiple relatively independent processing stages such as message generation, message sending, message receiving, and message service, enabling different stages to be executed in parallel on different processor cores.

[0043] Figure 6 The communication task partitioning of a single host SDSM instance is shown.

[0044] The main thread executes the user program logic running on the software distributed shared memory system and is responsible for generating communication messages when necessary. When the main thread detects a software distributed shared memory event, such as a page fault, broadcast, lock request, lock release, or barrier synchronization event, it retrieves an idle message slot from the message pool and fills the slot with information such as message type, source host identifier, destination host identifier, message sequence number, and message payload to form a message to be sent. After the message is constructed, the main thread puts the message to be sent into the output queue and triggers the output condition to notify the sending thread to perform subsequent sending processing. After enqueuing the message, the main thread can continue executing its local program logic or wait for the corresponding conditions to be updated by the service thread if a remote response is required.

[0045] The sending thread processes messages awaiting transmission in the output queue. Upon detecting a message in the output queue, the sending thread retrieves the corresponding message and determines the target host and port based on the destination host identifier in the message. The sending thread then sends the message to the destination host via UDP. For messages requiring reliable delivery, the sending thread registers the message in a pending acknowledgment table after transmission and waits for an acknowledgment from the destination host. If no acknowledgment is received within a preset timeout, the sending thread retransmits the message; upon receiving the acknowledgment, the sending thread marks the message as acknowledged and releases or reuses the corresponding message slot. The sending thread can also perform compression, encryption, header padding, or sequence number padding on the message before transmission.

[0046] The listener thread listens on the local UDP communication port to receive messages from remote hosts. The listener thread can listen on multiple ports for receiving ordinary messages and acknowledgment messages. When the listener thread receives an ordinary message, it sends an acknowledgment message to the source host and performs necessary processing on the received message, such as decryption, decompression, filtering, deduplication, sorting, or integrity checks. After processing, the listener thread places the ordinary message into the input queue and triggers input conditions to notify the service thread to process it. When the listener thread receives an acknowledgment message, it updates the corresponding record in the pending acknowledgment message table based on the message sequence number, source host identifier, or destination host identifier in the acknowledgment message.

[0047] Service threads are used to process pending messages in the input queue. Upon detecting a pending message in the input queue, a service thread retrieves the message and executes the corresponding software distributed shared memory service based on the message type. Services may include page request processing, page authorization processing, lock request processing, lock authorization processing, barrier request processing, barrier authorization processing, or broadcast message processing. Service threads can be configured as a unified service thread, capable of handling all message types; or they can be configured as multiple dedicated service threads, each handling specific message types. Multiple service threads can retrieve different messages from the input queue in parallel to improve the service capacity of a single host for remote requests.

[0048] Under the above task division, the main thread is primarily responsible for program logic and message generation, the sending thread is primarily responsible for message sending, acknowledgment waiting, and timeout retransmission, the listening thread is primarily responsible for message receiving, acknowledgment replies, and receiver-side preprocessing, and the service thread is primarily responsible for executing software distributed shared memory semantic services. The threads coordinate with each other through a message pool, output queue, input queue, pending message table, and communication manager.

[0049] Furthermore, to ensure correctness during multi-threaded parallel processing, synchronization mechanisms are implemented between threads. When the main thread and service threads access the same shared page, lock object, or barrier object, they synchronize using atomic variables, locks, or wait conditions. When multiple service threads process messages involving the same shared object, critical sections prevent duplicate or conflicting services. Sending and listening threads achieve cross-host synchronization through acknowledgment and pending acknowledgment message tables. Listening and service threads synchronize using the empty / full state of the input queue, while the main thread, service threads, and sending threads synchronize using the empty / full state of the output queue.

[0050] By dividing the communication tasks as described above, this application organizes the communication processing in a UDP-based software distributed shared memory system into a multi-threaded pipeline, avoiding the bottleneck caused by a single-threaded signal handler serially processing all messages, and fully utilizing the parallel processing capabilities of multi-core hosts to improve the message processing efficiency of the software distributed shared memory system in a multi-host environment.

[0051] Communication port design Figure 7 The design of the communication port in an embodiment of the present invention is shown. For example... Figure 7 As shown, in a UDP-based software distributed shared memory system, each host is configured with a sending port, a normal message receiving port, and an acknowledgment message receiving port. The sending port is used to send normal messages or acknowledgment messages to the remote host; the normal message receiving port is used to receive normal messages from the remote host; and the acknowledgment message receiving port is used to receive acknowledgment messages, i.e., ACK messages, returned by the remote host.

[0052] In this embodiment, the software distributed shared memory system includes N hosts, each with a unique host identifier, which can be an integer between 0 and N-1. The base port is further defined as B. For any receiving host, its ordinary message receiving port for receiving ordinary messages from host i is configured as B+i, where i is the host identifier of the message source host. The acknowledgment message receiving port for receiving acknowledgment messages is configured as B+N. The sending port uses a randomly available port or a temporarily available port allocated by the operating system for the UDP socket.

[0053] Therefore, when host i sends a normal message to host j, host i sends the message to the normal message receiving port B+i on host j via a randomly available local sending port. After receiving the message at port B+i, host j can determine or verify that the message originated from host i based on the receiving port. Upon receiving the message, host j returns an ACK message to host i's acknowledgment message receiving port B+N. The ACK message can carry information such as the message sequence number, source host identifier, and destination host identifier of the message being acknowledged, allowing host i to determine the specific message being acknowledged based on the pending acknowledgment message table.

[0054] by Figure 7Taking the communication between two hosts as an example, assume the system includes host 0 and host 1, i.e., N=2, and the base port is port0. For host 0, its sending port is bound to a randomly available port; its ordinary message receiving port for receiving ordinary messages from host 1 is port1, i.e., port0+1; its acknowledgment message receiving port is port2, i.e., port0+N. For host 1, its sending port is also bound to a randomly available port; its ordinary message receiving port for receiving ordinary messages from host 0 is port0, i.e., port0+0; its acknowledgment message receiving port is port2, i.e., port0+N. Therefore, port1=port0+1, and port2=port0+N.

[0055] Specifically, when host 0 sends a normal message to host 1, host 0 sends the message to port 0 of host 1 via a randomly available local port. After receiving the message at port 0, host 1 sends an ACK message to port 2 of host 0. Conversely, when host 1 sends a normal message to host 0, host 1 sends the message to port 1 of host 0 via a randomly available local port. After receiving the message at port 1, host 0 sends an ACK message to port 2 of host 1.

[0056] Through the above port design, the ordinary message receiving port and the message source host identifier have a definite correspondence, allowing the receiving host to quickly distinguish or verify the source of ordinary messages based on the receiving port. Simultaneously, all ACK messages are uniformly sent to the recipient's acknowledgment message receiving port B+N, enabling the sender to complete the acknowledgment matching using the pending acknowledgment message table and the message sequence number in the ACK message. Compared to a tiled port design that sets separate request and response ports for each pair of hosts, in this embodiment, the number of ordinary message receiving ports per host increases linearly with the number of hosts N, and only one additional acknowledgment message receiving port is required, thereby reducing port usage and port management complexity.

[0057] In other embodiments, the base port B can be determined during initialization by the system configuration file, startup parameters, or the communication manager. As long as each host has a consistent base port B, system size N, and host identifier mapping, the configuration of the normal message receiving port and the acknowledgment message receiving port can be completed according to the B+i and B+N rules.

[0058] Thread synchronization design In this embodiment of the application, since message generation, message sending, message receiving and message service in the UDP-based software distributed shared memory system are executed by the main thread, the sending thread, the listening thread and the service thread respectively, a synchronization mechanism needs to be set up between the threads to ensure the semantic correctness of the software distributed shared memory when multiple threads process messages in parallel.

[0059] The inter-thread synchronization in this embodiment includes synchronization between threads within the same host, and cross-host synchronization between different hosts via UDP messages and acknowledgment messages. Synchronization can be achieved through at least one of the following: atomic variables, atomic instructions, locks, wait conditions, queue empty / full states, message status fields, pending acknowledgment message tables, and acknowledgment messages. A schematic diagram of the thread synchronization design can be found here. Figure 6 .

[0060] 1) Message slot synchronization The message pool consists of multiple reusable message slots. To prevent multiple threads from using the same message slot simultaneously, each message slot has a message status field. The message status field can indicate that the message slot is in one of the following states: idle, under construction, pending, sending, awaiting acknowledgment, pending service, serviced, or completed.

[0061] When the main thread needs to generate a message to be sent, it atomically requests an idle message slot from the message pool and changes the slot's status from idle to under construction. Once the message is constructed, the main thread changes the slot's status to pending sending and adds the corresponding slot index to the output queue.

[0062] After retrieving the slot index from the output queue, the sending thread changes the status of the corresponding message slot to "sending". For messages requiring acknowledgment, the sending thread changes the status of the message slot to "awaiting acknowledgment" after sending and registers the message in the pending acknowledgment message table. When the corresponding acknowledgment message is received, the message slot can be marked as completed and, when the release condition is met, changed back to an idle state for reuse by subsequent messages.

[0063] After receiving a regular message, the listening thread can request an idle message slot from the message pool and write the received message into that slot. Once writing is complete, the listening thread changes the slot's status to "Pending Service" and adds the corresponding slot index to the input queue. The service thread retrieves the slot index from the input queue, changes the corresponding message slot's status to "Service in Progress," and after service completion, changes the slot's status to "Completed" or "Idle."

[0064] By atomically modifying the message status field as described above, it can be ensured that the same message slot is occupied by only one thread at a time, thereby avoiding concurrent write conflicts to the same message slot by the main thread, sending thread, listening thread, and service thread.

[0065] 2) Output queue synchronization The output queue is used to pass messages to be sent between the main thread, service threads, and sending threads. After detecting a software-distributed shared memory event and generating a message to be sent, the main thread writes the slot index corresponding to that message to the output queue. When a service thread needs to return a response message after processing certain input messages, it can also generate a response message and put it into the output queue. The sending thread then retrieves the message from the output queue and performs UDP transmission.

[0066] In one implementation, the output queue is a circular, lock-free queue, managed by head and tail pointers for enqueue and dequeue positions. When the main thread or service thread performs an enqueue operation, it updates the tail pointer atomically; when the sending thread performs a dequeue operation, it updates the head pointer atomically. If the output queue is empty, the sending thread enters a waiting state; when the main thread or service thread writes a new message to the output queue, it triggers an output condition to wake up or notify the sending thread. If the output queue is full, the main thread or service thread can wait for an empty position to appear, or back off, retry, or expand the queue according to a preset strategy.

[0067] By synchronizing the output queue as described above, the message generation task and the message sending task can be decoupled, avoiding the main thread directly executing remote communication, which would cause the program logic to be blocked for a long time.

[0068] 3) Input queue synchronization The input queue is used to pass pending messages between listening threads and service threads. After receiving a normal message and performing acknowledgment, deduplication, or integrity checks, the listening thread writes the slot index corresponding to the normal message into the input queue. One or more service threads retrieve messages from the input queue and execute the corresponding software distributed shared memory service based on the message type.

[0069] In one implementation, the input queue is a circular, lock-free queue, with enqueue and dequeue positions managed by head and tail pointers. When a listening thread performs an enqueue operation, it updates the tail pointer atomically; when a service thread performs a dequeue operation, it updates the head pointer atomically. If the input queue is empty, the service thread enters a waiting state; when a listening thread writes a new message to the input queue, it triggers an input condition to wake up one or more service threads. If the input queue is full, the listening thread can wait for an empty position to appear, or perform backoff, resizing, or discarding of abnormal messages according to a preset strategy.

[0070] By synchronizing the input queue as described above, the message receiving task and the message service task can be decoupled, allowing the listening thread to return to the UDP listening state as soon as possible, thereby improving the throughput of the receiving side.

[0071] 4) Confirmation synchronization between the sending thread and the remote listening thread Since UDP itself does not guarantee that messages will arrive, in this embodiment of the application, the sending thread and the listening thread of the remote host achieve cross-host synchronization through acknowledgment messages.

[0072] After sending a normal message requiring acknowledgment, the sending thread registers the message in the pending acknowledgment message table. The pending acknowledgment message table can record the message sequence number, destination host identifier, sending time, number of retransmissions, message slot index, and acknowledgment status. The sending thread then waits for the corresponding acknowledgment message.

[0073] Upon receiving the ordinary message, the listening thread of the remote host sends an acknowledgment message to the acknowledgment message receiving port of the message source host. The acknowledgment message may include at least one of the message sequence number of the message being acknowledged, the source host identifier, and the destination host identifier. After receiving the acknowledgment message, the message source host looks up the message to be acknowledged in the message acknowledgment table based on the message sequence number, source host identifier, or destination host identifier in the acknowledgment message, and marks the corresponding message as acknowledged.

[0074] If the sending thread does not receive the corresponding acknowledgment message within the preset timeout period, it retransmits the message according to the message slot index in the pending acknowledgment message table. If the number of retransmissions reaches a preset threshold and still no acknowledgment message is received, a communication anomaly can be reported or a fault handling procedure can be triggered. Through the above-mentioned acknowledgment synchronization, the reliability of SDSM message transmission can be improved on the basis of UDP communication.

[0075] 5) Synchronization between service threads A service thread can be set to one or more. When multiple service threads are set, they can retrieve different messages from the input queue in parallel and execute the corresponding services. To prevent multiple service threads from processing the same message simultaneously, the dequeue operation of the input queue is implemented through atomic operations, ensuring that each message to be served can only be successfully retrieved by one service thread.

[0076] Furthermore, when multiple service threads process messages involving the same shared object, synchronization protection needs to be set for that shared object. Shared objects can include shared pages, lock objects, barrier objects, or other software distributed shared memory metadata. For example, when two service threads both need to modify the state of the same shared page, they need to compete for the page state lock or atomic flag corresponding to that shared page. Only the service thread that successfully acquires the lock or atomic flag can enter the critical section to modify the shared page state. As another example, when multiple service threads process request messages for the same lock object, the modification of the lock state needs to be serialized through the protection variable corresponding to that lock object.

[0077] The above synchronization allows different service threads to process non-conflicting messages in parallel, while ensuring that messages involving the same shared object are executed in a protected manner, avoiding duplicate services, out-of-order updates, or state corruption.

[0078] 6) Synchronization between service threads and the main thread In a software-distributed shared memory system, the main thread executes user program logic, while service threads may modify shared memory regions or shared memory states accessible to the main thread based on remote messages. Therefore, when the messages processed by the service thread involve data accessible to the main thread, a synchronization mechanism needs to be set up between the service thread and the main thread.

[0079] For example, when the main thread accesses a shared page but a valid copy does not exist locally, the main thread generates a page request message and enters a waiting state. After the remote host returns a page authorization message, the local listening thread puts the page authorization message into the input queue, and the local service thread retrieves the page authorization message from the input queue and writes the page data into the local shared page cache. The main thread must not access the shared page until the page data is completely written. To this end, a page state variable can be set for the shared page, which can include states such as invalid, requesting, updating, and valid. The main thread waits when the page state is invalid, requesting, or updating; after the service thread completes the page data copy and updates the page metadata, it changes the page state to valid and wakes up or releases the main thread from the waiting condition.

[0080] For example, when a service thread processes a lock authorization message or a barrier authorization message, it can update the lock authorization status or barrier completion status through atomic variables. While waiting for lock authorization or barrier completion, the main thread waits or polls the corresponding atomic variables. After the service thread completes the status update, the main thread continues to execute subsequent user program logic.

[0081] By synchronizing the service thread with the main thread as described above, we can prevent the main thread from reading shared page data that has not been updated, or from continuing to execute based on lock states or barrier states that have not been updated, thereby ensuring the correctness of the execution of the software distributed shared memory system.

[0082] 7) Synchronization between threads on different hosts This application also includes synchronization between threads on different hosts. This synchronization typically begins with the main thread on one host waiting for a certain condition to begin, followed by a service thread on another host performing a service and returning a response message, and finally ending with the local service thread updating the waiting condition.

[0083] For example, when the main thread of the first host requests a shared page on the second host, the main thread of the first host generates a page request message and waits for the page state to be updated. The sending thread of the first host sends the page request message to the second host. The listening thread of the second host receives the page request message and sends an acknowledgment message. The service thread of the second host processes the page request and generates a page grant message. After the page grant message is returned to the first host, the listening thread of the first host puts the page grant message into the input queue. The service thread of the first host processes the page grant message and updates the local page state. The main thread of the first host continues execution after detecting that the page state has been updated.

[0084] Thus, cross-host synchronization is achieved through ordinary messages, acknowledgment messages, response messages, and wait conditions within the local host.

[0085] Shared memory system message handling methods In the above embodiments, this application provides a message processing method for a UDP-based distributed shared memory system. The distributed shared memory system includes multiple hosts, each running a software distributed shared memory system instance. The method includes: Initialize the communication manager, message pool, input queue, and output queue. The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message acknowledgment information. The message pool includes multiple reusable message slots. Create a main thread, a sending thread, a listening thread, and at least one service thread; When the main thread detects a software distributed shared memory event, it retrieves an idle message slot from the message pool, generates a message to be sent, and puts the message to be sent into the output queue. The sending thread retrieves the message to be sent from the output queue and sends the message to the destination host via UDP. The listening thread listens for UDP messages from the remote host. Upon receiving a normal message, it sends an acknowledgment message to the message source host and puts the received normal message into the input queue. The service thread retrieves messages from the input queue and executes the corresponding software distributed shared memory service based on the message type.

[0086] Each host's UDP port may include a sending port, multiple ordinary message receiving ports, and an acknowledgment message receiving port. The sending port is a randomly available port. The multiple ordinary message receiving ports correspond to different message source host identifiers in the software distributed shared memory system, so that the receiving host can determine or verify the message source host of the ordinary message based on the ordinary message receiving port of the ordinary message. The acknowledgment message receiving port is determined according to the number N of hosts in the software distributed shared memory system.

[0087] When the first host sends a normal message to the second host, the first host sends the normal message to the normal message receiving port on the second host that corresponds to the host identifier of the first host; After the second host receives a normal message, the second host will send an acknowledgment message to the acknowledgment message receiving port of the first host.

[0088] Each message slot in the message pool includes a message status field, a message type field, a source host identifier field, a destination host identifier field, a message sequence number field, and a message payload field; The message status field is used to indicate that the corresponding message slot is in one of the following states: idle, under construction, pending, sending, waiting for confirmation, pending service, in service, or completed. When a message slot flows between the main thread, the sending thread, the listening thread, and the service thread, the message status field is modified through atomic operations to ensure that the same message slot is occupied by only one thread at a time.

[0089] The input queue and output queue can be lock-free queues, and the message pool is a lock-free message pool. The lock-free queue and lock-free message pool implement at least one of the following operations through atomic variables or atomic instructions: enqueue, dequeue, request message slot, and release message slot.

[0090] After sending a message that requires acknowledgment, the sending thread registers the message to be acknowledged in the pending acknowledgment message table; when it receives an acknowledgment message corresponding to the message that requires acknowledgment, it marks the message that requires acknowledgment as acknowledged; if no acknowledgment message corresponding to the message that requires acknowledgment is received within a preset timeout period, the message that requires acknowledgment is resent; wherein, the acknowledgment message includes at least one of the message sequence number of the acknowledged message, the source host identifier, and the destination host identifier.

[0091] Multiple service threads retrieve different messages from the input queue in parallel, and when a service thread processes a message involving the same shared page, the same lock object, or the same barrier object, the corresponding critical section is protected by atomic variables or locks. When a message processed by a service thread involves writing data to a shared memory area accessible to the main thread or modifying the shared memory state, the service thread synchronizes with the main thread through atomic variables, locks, or wait conditions to prevent the main thread from accessing shared memory data or state that has not been updated.

[0092] Software distributed shared memory system In summary, this application provides a UDP-based software distributed shared memory system, comprising N hosts, where N is an integer greater than 1, and each host includes: The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message confirmation information. A message pool consists of multiple reusable message slots; The output queue is used to buffer messages to be sent. The input queue is used to cache messages waiting to be served. The main thread execution module is used to obtain an idle message slot from the message pool, generate a message to be sent, and put the message to be sent into the output queue when a software distributed shared memory event is detected. The sending thread execution module is used to retrieve messages to be sent from the output queue and send the messages to be sent to the destination host via UDP; The listener thread execution module is used to listen for UDP messages from remote hosts. After receiving a normal message, it sends an acknowledgment message to the message source host and puts the received normal message into the input queue. The service thread execution module is used to retrieve messages from the input queue and execute the corresponding software distributed shared memory service according to the message type.

[0093] Each host's UDP port may include a sending port, multiple ordinary message receiving ports, and an acknowledgment message receiving port. The sending port is a randomly available port. The multiple ordinary message receiving ports correspond to different message source host identifiers in the software distributed shared memory system. The acknowledgment message receiving port is determined based on the number N of hosts in the software distributed shared memory system.

[0094] In some example implementations, the base port is set to B, and the message source host identifier is set to i, where i is an integer between 0 and N-1; The normal message receiving port on each host for receiving normal messages from host i is B+i; The acknowledgment message receiving port on each host is B+N.

[0095] In some example implementations, each message slot in the message pool includes a message status field, a message type field, a source host identifier field, a destination host identifier field, a message sequence number field, and a message payload field. The message status field is used to indicate that the corresponding message slot is in one of the following states: idle, under construction, pending transmission, sending, awaiting acknowledgment, pending service, in service, or completed. The input queue and output queue are lock-free queues, and the message pool is a lock-free message pool. The lock-free queue and the lock-free message pool implement message slot flow through atomic variables or atomic instructions.

[0096] In some example implementations, the sending thread execution module is used to register the message requiring confirmation to the message to be confirmed table after sending the message that requires confirmation; The listening thread execution module is used to determine the corresponding message in the message to be confirmed table based on at least one of the message sequence number, source host identifier and destination host identifier in the confirmation message after receiving the confirmation message; The sending thread execution module is also used to resend the message that needs to be confirmed if no confirmation message corresponding to the message that needs to be confirmed is received within a preset timeout period.

[0097] In some example implementations, the service thread execution module includes multiple service threads, which are used to retrieve different messages from the input queue in parallel; When multiple service threads are processing messages involving the same shared page, the same lock object, or the same barrier object, they protect the corresponding critical sections using atomic variables or locks. When any of the multiple service threads processes a message that involves writing data to a shared memory area accessible to the main thread or modifying the shared memory state, each service thread synchronizes with the main thread execution module through atomic variables, locks, or wait conditions to prevent the main thread execution module from accessing shared memory data or state that has not been updated.

[0098] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0099] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A message processing method for a UDP-based distributed shared memory system, wherein the distributed shared memory system comprises multiple hosts, each host running a software distributed shared memory system instance, characterized in that, include: Initialize the communication manager, message pool, input queue, and output queue. The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message acknowledgment information. The message pool includes multiple reusable message slots. Create a main thread, a sending thread, a listening thread, and at least one service thread; When the main thread detects a software distributed shared memory event, it obtains an idle message slot from the message pool, generates a message to be sent, and puts the message to be sent into the output queue. The sending thread retrieves the message to be sent from the output queue and sends the message to the destination host via UDP. The listening thread listens for UDP messages from a remote host, sends an acknowledgment message to the message source host upon receiving a normal message, and puts the received normal message into the input queue. The service thread retrieves messages from the input queue and executes the corresponding software distributed shared memory service according to the message type.

2. The method according to claim 1, characterized in that, Each host's UDP port includes a sending port, multiple ordinary message receiving ports, and an acknowledgment message receiving port. The sending port is a randomly available port. The multiple ordinary message receiving ports correspond to different message source host identifiers in the software distributed shared memory system, so that the receiving host can determine or verify the message source host of the ordinary message based on the ordinary message receiving port that receives the ordinary message. The acknowledgment message receiving port is determined based on the number N of hosts in the software distributed shared memory system.

3. The method according to claim 1 or 2, characterized in that, Let the base port be B and the message source host identifier be i, where i is an integer between 0 and N-1; The normal message receiving port on each host for receiving normal messages from host i is B+i; The acknowledgment message receiving port on each host is B+N.

4. The method according to claim 3, characterized in that, When the first host sends a normal message to the second host, the first host sends the normal message to the normal message receiving port on the second host that corresponds to the host identifier of the first host; When the second host receives the normal message, the second host will send an acknowledgment message to the acknowledgment message receiving port of the first host.

5. The method according to claim 1, characterized in that, Each message slot in the message pool includes a message status field, a message type field, a source host identifier field, a destination host identifier field, a message sequence number field, and a message payload field; The message status field is used to indicate that the corresponding message slot is in one of the following states: idle, under construction, waiting to be sent, sending, waiting for confirmation, waiting to be served, serving, or completed. When the message slot flows between the main thread, the sending thread, the listening thread, and the service thread, the message status field is modified through atomic operations so that the same message slot is occupied by only one thread at any given time.

6. The method according to claim 1, characterized in that, The input queue and the output queue are lock-free queues, and the message pool is a lock-free message pool. The lock-free queue and the lock-free message pool implement at least one of the following operations through atomic variables or atomic instructions: enqueueing, dequeueing, requesting a message slot, and releasing a message slot.

7. The method according to claim 1, characterized in that, After sending a message that requires confirmation, the sending thread registers the message that requires confirmation in the message to be confirmed table. Upon receiving a confirmation message corresponding to the message requiring confirmation, the message requiring confirmation is marked as confirmed. If no confirmation message corresponding to the message requiring confirmation is received within the preset timeout period, the message requiring confirmation is resent. The confirmation message includes at least one of the following: the message sequence number of the confirmed message, the source host identifier, and the destination host identifier.

8. The method according to claim 1, characterized in that, Multiple service threads retrieve different messages from the input queue in parallel, and when a service thread processes a message involving the same shared page, the same lock object, or the same barrier object, the corresponding critical section is protected by atomic variables or locks. When a message processed by a service thread involves writing data to a shared memory region accessible to the main thread or modifying the shared memory state, the service thread synchronizes with the main thread through atomic variables, locks, or wait conditions to prevent the main thread from accessing shared memory data or state that has not been updated.

9. A software-distributed shared memory system based on UDP, characterized in that, It includes N hosts, where N is an integer greater than 1. Each host includes: The communication manager is used to record the local host identifier, remote host communication information, communication port information, and message confirmation information. A message pool consists of multiple reusable message slots; The output queue is used to buffer messages to be sent. The input queue is used to cache messages waiting to be served. The main thread execution module is used to obtain an idle message slot from the message pool, generate a message to be sent, and put the message to be sent into the output queue when a software distributed shared memory event is detected. The sending thread execution module is used to retrieve the message to be sent from the output queue and send the message to be sent to the destination host via UDP. The listening thread execution module is used to listen for UDP messages from a remote host. After receiving a normal message, it sends an acknowledgment message to the message source host and puts the received normal message into the input queue. The service thread execution module is used to retrieve messages from the input queue and execute the corresponding software distributed shared memory service according to the message type.

10. The system according to claim 9, characterized in that, Each host's UDP port includes a sending port, multiple ordinary message receiving ports, and an acknowledgment message receiving port. The sending port is a randomly available port. The multiple ordinary message receiving ports correspond to different message source host identifiers in the software distributed shared memory system. The acknowledgment message receiving port is determined based on the number N of hosts in the software distributed shared memory system.

11. The system according to claim 9, characterized in that, Let the base port be B and the message source host identifier be i, where i is an integer between 0 and N-1; The normal message receiving port on each host for receiving normal messages from host i is B+i; The acknowledgment message receiving port on each host is B+N.

12. The system according to claim 9, characterized in that, Each message slot in the message pool includes a message status field, a message type field, a source host identifier field, a destination host identifier field, a message sequence number field, and a message payload field; The message status field is used to indicate that the corresponding message slot is in one of the following states: idle, under construction, waiting to be sent, sending, waiting for confirmation, waiting to be served, serving, or completed. The input queue and the output queue are lock-free queues, and the message pool is a lock-free message pool. The lock-free queue and the lock-free message pool implement message slot flow through atomic variables or atomic instructions.

13. The system according to claim 9, characterized in that, The sending thread execution module is used to register the message requiring confirmation to the message to be confirmed table after sending the message requiring confirmation. The listening thread execution module is used to determine the corresponding message in the message to be confirmed table after receiving the confirmation message, based on at least one of the message sequence number, source host identifier and destination host identifier in the confirmation message; The sending thread execution module is also used to resend the message requiring confirmation if no confirmation message corresponding to the message requiring confirmation is received within a preset timeout period.

14. The system according to claim 9, characterized in that, The service thread execution module includes multiple service threads, which are used to retrieve different messages from the input queue in parallel. When the multiple service threads process messages involving the same shared page, the same lock object, or the same barrier object, they protect the corresponding critical sections using atomic variables or locks. When any of the multiple service threads processes a message that involves writing data to a shared memory area accessible to the main thread or modifying the shared memory state, the service thread synchronizes with the main thread execution module through atomic variables, locks, or wait conditions to prevent the main thread execution module from accessing shared memory data or state that has not been updated.

Images