Method and system for realizing subscription and release communication mode based on Feiteng FT-6678N SRIO link

Abstract

The invention provides a method and a system for realizing a'subscription and release 'communication mode based on a Feiteng FT-6678N SRIO link. The method provided by the invention comprises the following steps: responding to the calling of a communication interface haosipublist (), sending a first data packet representing a publisher to each node of the parallel computing system, and creating a communication group; responding to a received second data packet which carries the theme to be subscribed and the network address of the subscriber and represents the subscriber, and if the theme to be subscribed is consistent with the theme to be published, taking the subscriber as a slave member of the created communication group; sending a second data packet representing a subscriber to each node of the parallel computing system in response to the calling of a communication interface haosisubscript (), and taking the second data packet as a slave member of a communication group; in response to receiving a first data packet representative of a publisher carrying a subject to be published and a publisher network address, the publisher is taken as a master member of a communication group associated with the subject to be subscribed.

Description

Technical Field

[0001] The present application relates to a distributed computing system, and in particular to a method and system for implementing a "subscribe and publish" communication mode in a distributed computing system based on Feiteng FT-6678N, and adopts a non-blocking implementation method to enable communication to be carried out in parallel with computing, greatly improving the utilization efficiency of the FT-6678N processor, and is particularly suitable for a distributed parallel computing system of multiple FT-6678N or multiple general-purpose processors. Background Art

[0002] MPI (Message Passing Interface) is a message passing interface for parallel computing. It is also a standard description of a message passing function library. It provides two communication modes: point-to-point communication and group communication between processes. In the MPI-based programming model, the computing system includes one or more processes that communicate with each other by calling library functions to send and receive messages. MPI provides a parallel environment library for programmers. Programmers can achieve their desired parallel computing goals by calling MPI library programs.

[0003] MPI generally runs on general-purpose processors, mainly in Windows or Linux environments, and messages between different nodes are transmitted via Ethernet. The node of MPI refers to a single computing unit that participates in parallel computing. A node can be an independent computer or a single processor in a multi-processor system. Each node runs one or more processes, which communicate and collaborate through MPI.

[0004] There is an SRIO (Serial RapidIO) communication link between multiple FT-6678Ns. Its data communication rate (3.125G, X4 mode) is 10 times that of Gigabit Ethernet. In addition, the DMA communication method can be used for data transmission, which can complete data transmission without the participation of the processor, greatly reducing the processor load and allowing the processor to focus on calculations instead of spending a lot of time to complete data transmission, thereby improving the processor utilization rate.

[0005] MPI is based on a general-purpose operating system, which is rich in functions and highly dependent on general-purpose operating systems. In addition, the underlying layer only provides support for the network but lacks support for SRIO links. However, the Feiteng FT-6678N runs a lightweight embedded operating system, and it is difficult to implement MPI migration in this system.

[0006] The "Publish & Subscribe" communication mode is a message communication mode and also a software architecture design mode. It is used to decouple the publisher and receiver of messages. In this communication mode, the message publisher is responsible for publishing messages, and the subscriber can choose to subscribe to the message topics of interest. When the publisher has a new message to publish, the subscriber will receive the corresponding message. In the "Subscribe & Publish" communication mode, publishers and subscribers transmit messages based on topics, for example. The publisher generates a message with a certain topic, and the subscribers of the topic will receive the message under the topic. The behavior of the publisher and the receiver is simplified to publishing and receiving messages on a specific topic, without having to care about each other's network addresses, the time when the message is generated and received, and the publishing and receiving process of the message will not cause blocking of the message communication peer. Publishers and subscribers can exist and operate independently of each other.

[0007] Using the subscription and publication communication mode in a distributed computing system can simplify the complexity of message communication between message publishers and subscribers. There can be multiple publishers and multiple subscribers in a distributed computing system. For a specific topic, the publisher of the topic's message is unique, and there can be multiple subscribers. The publisher can publish messages based on different topics at the same time, and can also publish multiple messages based on the same topic. Subscribers can also receive messages from different topics at the same time. Summary of the invention

[0008] The system framework used in traditional underwater acoustic signal processing is a data flow model implemented based on a highly parallel computing platform. In the underwater acoustic signal processing system, each computing node performs computing and communication work concurrently in a software pipeline manner, and each computing node collaborates to complete high-performance underwater acoustic computing tasks. Such an architecture requires each node in the system to independently complete the operations of data reception, signal processing calculation, and data transmission, and to achieve decoupling as much as possible. Each node runs concurrently according to its own beat (data reception, signal processing calculation, and data transmission). In this mode, two problems will arise: First, the communication between computing nodes (data reception and data transmission beats) usually takes a long time. When the blocking communication has not ended, the signal processing calculation beat of the computing node cannot be executed and can only wait, thereby wasting the computing resources of the node; second, the communication methods based on the network, SRIO, and shared memory all involve specific implementations related to the underlying hardware (for example, when using Ethernet links at the bottom layer, it is necessary to know the IP addresses and communication port numbers of the communicating parties in advance; when using SRIO links at the bottom layer, it is necessary to know the destination ID and data storage address of the other end in advance; when using shared links at the bottom layer, it is necessary to know the data storage address of the other end in advance). To avoid conflicts, in a system with multiple FT-6678Ns, the network IP address, SRIO ID and other information are bound to the physical location of the FT-6678N (such as chassis, slot, etc.), which ultimately results in the application being able to run only on the FT-6678N at a fixed physical location in the system. This limits the duplication and distribution of applications. An application developed for a multi-processor distributed parallel computing system based on Feiteng FT-6678N can only run on that system. If you want to run it on another distributed computing system, you need to perform complex development and adaptation work.

[0009] Furthermore, due to the lack of support from basic software, current applications for multi-processor distributed parallel computing systems based on Feiteng FT-6678N cannot perform message communication based on the subscription and publication communication model.

[0010] To solve one or more of the above technical problems, according to an embodiment of the present application, a message communication middleware is provided. Middleware is an independent software located between different applications or between different parts of distributed applications, providing them with communication and data management services. It acts as a bridge, enabling different applications to interact with each other without the need for developers to understand the underlying communication details. The message communication middleware provided encapsulates the communication methods such as Ethernet, SRIO link and memory sharing in the multi-processor distributed parallel computing system based on Feiteng FT-6678N, isolates the user application from the specific hardware implementation, and provides users with a simple function interface to implement data communication and synchronization methods between nodes, reducing the development cycle and development difficulty of developers of high-performance signal processing tasks, and improving the reliability and scalability of the system. And the use of non-blocking communication mode makes the signal processing calculation beat in the application parallel or overlap with the communication beat, thereby improving the efficiency of application execution.

[0011] Furthermore, the "subscribe and publish" communication mode is also supported through, for example, middleware. Communication interfaces representing "publish" (such as haos_i_publish()) and "subscribe" (such as haos_i_subscriber()) are provided for applications that wish to communicate messages. The publisher of the message is allowed to simply call the publishing communication interface, and the receiver of the message is allowed to call the receiving communication interface to implement message communication in a multi-processor distributed parallel computing system based on Feiteng FT-6678N.

[0012] According to a first aspect of the present application, a first method for message communication middleware according to the first aspect of the present application is provided, wherein the message communication middleware runs on each node of a Feiteng FT-6678N multi-processor distributed parallel computing system, and the nodes are interconnected through an SRIO communication link. The method comprises: in response to the communication interface haos_i_send() being called, obtaining parameters representing a communication group and parameters representing data to be sent from the communication interface, and returning the call to the communication interface haos_i_send(); if the node calling the communication interface haos_i_send() is the master member of the communication group, sending an information packet to the slave member of the communication group to inform the slave member of the communication group that it has called the communication interface haos_i_send(). d(), and inform the data cache address of the data to be sent; in response to the communication interface haos_i_recv() being called, obtain the parameters representing the communication group and the parameters representing the data cache for receiving data from the communication interface, and return the call to the communication interface haos_i_recv(); if the node calling the communication interface haos_i_recv() is a slave member of the communication group, determine whether the master member of the communication group has called the communication interface haos_i_send(); if the master member of the communication group has called the communication interface haos_i_send(), move the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; if the master member of the communication group has not called the communication interface haos_i_send(), mark that it is ready to receive data; in response to receiving the code from the master member of the communication group The master member of the communication group indicates that the master member has called the information packet of the communication interface haos_i_send(). If the slave member of the communication group is ready to receive data, the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; in response to receiving the data to be sent from the master member of the communication group, the communication process corresponding to the communication interface haos_i_recv() is marked as completed, and an information packet representing that the data to be sent has been received is sent to the master member of the communication group; in response to receiving the information packet representing that the data to be sent has been received from the slave member of the communication group, the master member of the communication group that has called the communication interface haos_i_send() marks that the communication process corresponding to the communication interface haos_i_send() has been completed.

[0013] According to the second method for message communication middleware of the first aspect of the present application, wherein: the master member of the communication group informs the slave members of the communication group that it has called the communication interface haos_i_send() by sending a HAOS_SNDRDY information packet to the slave members of the communication group; the slave members of the communication group inform the master member of the communication group that it has received the data to be sent by sending a HAOS_SNDOK information packet to the master member of the communication group.

[0014] According to the third method for message communication middleware of the first aspect of the present application, the method further includes: the slave member of the communication group listens in the daemon thread for the HAOS_SNDRDY information packet from the master member of the communication group; in response to the communication interface haos_i_recv() being called, if the node calling the communication interface haos_i_recv() is the slave member of the communication group, and the master member of the communication group has called the communication interface haos_i_send(), the master thread of the node calling the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; in response to receiving the message from the master member of the communication group indicating that the master member of the communication group has called the communication interface haos_i_send() d(), if the slave member of the communication group is ready to receive data, the daemon thread of the node of the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; the daemon thread of the slave member of the communication group, in response to receiving the data to be sent from the master member of the communication group, notifies the main thread of the slave member of the communication group that the communication process corresponding to the communication interface haos_i_recv() has been processed; the daemon thread of the master member of the communication group, in response to receiving the information packet from the slave member of the communication group informing it that it has received the data to be sent, notifies the main thread of the master member of the communication group that the communication process corresponding to the communication interface haos_i_send() has been processed.

[0015] According to the fourth method for message communication middleware according to the first aspect of the present application, it also includes: in response to the communication interface haos_i_test() being called, obtaining the communication process to be monitored from the communication interface, and generating a return value for the communication interface haos_i_test() and a call return to the communication interface haos_i_test() according to whether the communication process to be monitored has been processed; in response to the communication interface haos_i_wait() being called, obtaining the communication process to be monitored from the communication interface, if the communication process to be monitored has not been processed, blocking the call to the communication interface haos_i_wait(), and in response to the communication process to be monitored being processed, generating a return value for the communication interface haos_i_wait() representing that the communication process to be monitored has been processed, and a call return to the communication interface haos_i_wait().

[0016] According to the fifth method for message communication middleware of the first aspect of the present application, the communication group includes a master member and multiple slave members; if the node calling the communication interface haos_i_send() is the master member of the communication group, it sends the data to be sent to each slave member of the communication group; if the node calling the communication interface haos_i_recv() is the master member of the communication group, it receives the data to be sent from each slave member of the communication group.

[0017] The sixth method for message communication middleware according to the first aspect of the present application also includes: if the node calling the communication interface haos_i_send() is a slave member of the communication group, sending an information packet to the master member of the communication group to inform the master member of the communication group that it has called the communication interface haos_i_send(); in response to receiving an information packet indicating that the master member of the communication group has called the communication interface haos_i_recv(), the node of the communication interface haos_i_send() obtains the data cache address of the master member of the communication group for receiving the data to be sent from the information packet indicating that the master member of the communication group has called the communication interface haos_i_recv(), and sends the data to be sent to the data cache of the master member of the communication group for receiving the data to be sent; in response to sending the data to be sent to the master member of the communication group, marking that the communication process corresponding to the communication interface haos_i_send() has been processed, and sending a message to the master member of the communication group. a member sends an information packet representing that it has sent the data to be sent; if the node calling the communication interface haos_i_recv() is the master member of the communication group, if the slave member of the communication group has called the communication interface haos_i_send(), send an information packet indicating that it is ready to receive data to the slave member of the communication group, if the slave member of the communication group has not called the communication interface haos_i_send(), mark it as ready to receive data; if the master member of the communication group is ready to receive data, the node calling the communication interface haos_i_recv() responds to receiving the information packet indicating that the slave member of the communication group has called the communication interface haos_i_send(), sends an information packet indicating that it is ready to receive data to the slave member of the communication group; in response to receiving an information packet representing that the slave member of the communication group has sent the data to be sent from the master member of the communication group, mark the communication process corresponding to the communication interface haos_i_recv() as completed.

[0018] The seventh method for message communication middleware according to the first aspect of the present application also includes: in response to the communication interface haos_i_scatter() being called by the master member of the communication group, obtaining parameters representing the communication group and parameters representing the data to be sent from the communication interface, and returning the call to the communication interface haos_i_scatter(), wherein the communication group includes a master member and multiple slave members; if the node that calls the communication interface haos_i_scatter() is the master member of the communication group, sending an information packet to each slave member of the communication group to inform the slave members of the communication group that it has called the communication interface haos_i_scatter(), and informing the data cache address of the data to be sent; in response to the communication interface haos_i_recv() being called, obtaining parameters representing the communication group and parameters representing the data cache for receiving data from the communication interface, and returning the call to the communication interface haos_i_recv(); if the node that calls the communication interface haos_i_recv() is the slave member of the communication group, judging whether the master member of the communication group has called the communication interface haos_i_scatter(); if the master member of the communication group has called The communication interface haos_i_scatter() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; if the master member of the communication group has not called the communication interface haos_i_scatter(), it is marked as ready to receive data; in response to receiving an information packet from the master member of the communication group representing that the master member of the communication group has called the communication interface haos_i_scatter(), if it is ready to receive data, the node of the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; in response to receiving the data to be sent from the master member of the communication group, it is marked that the communication process corresponding to the communication interface haos_i_recv() has been processed, and sends the information packet representing that the data to be sent has been received to the master member of the communication group; in response to receiving an information packet from all slave members of the communication group representing that the data to be sent has been received, the master member of the communication group that has called the communication interface haos_i_scatter() marks that the communication process corresponding to the communication interface haos_i_scatter() has been processed.

[0019] The eighth method for message communication middleware according to the first aspect of the present application further includes: in response to the communication interface haos_i_gather() being called by the master member of the communication group, obtaining parameters representing the communication group and parameters representing the data to be sent from the communication interface, and returning the call to the communication interface haos_i_gather(), wherein the communication group includes a master member and multiple slave members; determining whether the slave member of the communication group has called the communication interface haos_i_send(); if the slave member of the communication group has called the communication interface haos_i_send(), sending a message to each slave member of the communication group that has called the communication interface haos_i_send() The first slave member sends an information packet indicating that it is ready to receive data. If one or more slave members of the communication group have not called the communication interface haos_i_send(), it is marked as ready to receive data. If the master member of the communication group is ready to receive data, in response to receiving an information packet indicating that one or more second slave members of the communication group have called the communication interface haos_i_send(), it sends an information packet indicating that it is ready to receive data to the one or more second slave members of the communication group. In response to receiving the data to be sent from all slave members of the communication group, it is marked that the communication process corresponding to the communication interface haos_i_gather() has been processed.

[0020] According to the second aspect of the present application, a first method for a node of a Feiteng FT-6678N multi-processor distributed parallel computing system, wherein the Feiteng FT-6678N multi-processor distributed parallel computing system includes a plurality of interconnected nodes, the nodes include a first inbound cache, a second inbound cache, a first outbound cache and a second outbound cache, the nodes run a message communication middleware, and the message communication middleware is the message communication middleware according to the second aspect of the present application; the method includes: repeatedly executing a task processing loop, performing the following steps in the task processing loop: calling a communication interface haos_i_recv() to use a first inbound cache to receive data from a first node interconnected with a current node, wherein the current node and the first node belong to a first communication group; calling a communication interface haos_i_send() to use a first outbound cache to receive data from a second node interconnected with the current node, wherein the current node and the second node belong to a second communication group; performing data processing using the data in the second inbound cache, and the result of the data processing is saved in the second outbound cache; waits for the communication process of calling the communication interface haos_i_recv() to use the first inbound cache to receive data from the first node interconnected with the current node to complete, and waits for the communication process of calling the communication interface haos_i_send() to use the first outbound cache to receive data from the second node interconnected with the current node to complete; calls the communication interface haos_i_recv() to use the second inbound cache to receive data from the first node interconnected with the current node; calls the communication interface haos_i_send() to use the second outbound cache to receive data from the second node interconnected with the current node; uses the data in the first inbound cache to perform data processing, and the result of the data processing is saved in the first outbound cache; waits for the communication process of calling the communication interface haos_i_recv() to use the second inbound cache to receive data from the first node interconnected with the current node to complete, and waits for the communication process of calling the communication interface haos_i_send() to use the second outbound cache to receive data from the second node interconnected with the current node to complete.

[0021] According to the second aspect of the present application, the second method for a node based on the Feiteng FT-6678N multi-processor distributed parallel computing system, wherein the communication interface haos_i_recv() and the communication interface haos_i_send() are both non-blocking; and in the task processing loop, the step of calling the communication interface haos_i_recv() to use the first inbound cache to receive data from the first node interconnected with the current node, the step of calling the communication interface haos_i_send() to use the first outbound cache to receive data to the second node interconnected with the current node, and the step of using the data from the second inbound cache to perform data processing are executed in parallel; and the step of calling the communication interface haos_i_recv() to use the second inbound cache to receive data from the first node interconnected with the current node, the step of calling the communication interface haos_i_send() to use the second outbound cache to receive data to the second node interconnected with the current node, and the step of using the data from the first inbound cache to perform data processing are executed in parallel.

[0022] According to a third aspect of the present application, a method for a first message communication middleware for implementing a subscription and publication communication mode according to the third aspect of the present application is provided, wherein the message communication middleware runs on each node of a Feiteng FT-6678N multi-processor distributed parallel computing system including multiple nodes, and each node is coupled via an SRIO link, and the method comprises: in response to a communication interface haos_i_publish() being called, obtaining parameters representing a topic to be published from the communication interface, sending a first data packet representing the publisher carrying the topic to be published and its own network address to each node of the parallel computing system, creating a communication group associated with the topic to be published, and itself as the primary member of the created communication group; in response to receiving a message carrying a topic to be subscribed a second data packet representing a subscriber carrying the topic to be subscribed and the network address of the subscriber, and if the topic to be subscribed is consistent with the topic to be published, the subscriber is used as a slave member of the created communication group; in response to the communication interface haos_i_subscribe() being called, the parameter representing the topic to be subscribed is obtained from the communication interface, and the second data packet representing the subscriber carrying the topic to be subscribed and its own network address is sent to each node of the parallel computing system, and itself is used as a slave member of the communication group associated with the topic to be subscribed; in response to receiving the first data packet representing the publisher carrying the topic to be published and the network address of the publisher, if the topic to be published is consistent with the topic to be subscribed, the publisher is used as the master member of the communication group associated with the topic to be subscribed.

[0023] A second method for implementing a subscription and publication communication mode of message communication middleware according to the third aspect of the present application is provided, wherein: in response to receiving a second data packet representing a subscriber carrying a subject to be subscribed and a network address of a subscriber, if the subject to be subscribed is consistent with the subject to be published, a response data packet is also sent to the subscriber; in response to receiving a response data packet to the first data packet sent by the subscriber, the subscriber is used as a slave member of the created communication group; in response to receiving a first data packet representing a publisher carrying a subject to be published and a network address of a publisher, if the subject to be published is consistent with the subject to be subscribed, a response data packet is also sent to the publisher; in response to receiving a response data packet to the second data packet sent by the publisher, the publisher is used as a master member of the created communication group.

[0024] A third method for message communication middleware for implementing a subscription and publication communication mode according to the third aspect of the present application is provided, wherein: the first data packet and the second data packet are UDP multicast packets; and the response data packet is a UDP unicast packet or a UDP multicast packet.

[0025] A fourth method for implementing a subscription and publication communication mode of message communication middleware according to the second aspect of the present application is provided, wherein: in response to receiving a second data packet on behalf of a subscriber carrying a topic to be subscribed and a network address of a subscriber, if the topic to be subscribed has not yet been published, the second data packet is cached and a response data packet is not sent to the subscriber; in response to receiving a first data packet on behalf of a publisher carrying a topic to be published and a network address of a publisher, if the topic to be published has not yet been subscribed, the first data packet is cached and a response data packet is not sent to the publisher.

[0026] A fifth method for implementing a subscription and publication communication mode of message communication middleware according to the second aspect of the present application is provided, wherein, in response to the communication interface haos_i_send() being called, parameters representing a communication group and parameters representing data to be sent are obtained from the communication interface, and the call to the communication interface haos_i_send() is returned; in response to the communication interface haos_i_recv() being called, parameters representing the communication group and parameters representing a data cache for receiving data are obtained from the communication interface, a cache address for receiving data is informed to a sender of the communication group, and the call to the communication interface haos_i_recv() is returned; in response to receiving a cache address for receiving data from a receiver of the communication group, the data to be sent is moved to the cache for receiving data, and the communication process corresponding to the communication interface haos_i_send() is marked as completed; in response to receiving data to be sent from the sender of the communication group, the communication process corresponding to the communication interface haos_i_recv() is marked as completed.

[0027] A sixth method for implementing a subscription and publication communication mode of message communication middleware according to the second aspect of the present application is provided, wherein, in response to the communication interface haos_i_recv() being called, a cache address for receiving data is sent to a sender of a communication group via a DIO mode, and a doorbell is also used to inform the sender of the communication group that the cache address for receiving data has been sent to it; in response to receiving the doorbell, the sender of the communication group recognizes that the cache address for receiving data has been received from the receiver of the communication group; in response to receiving the cache address for receiving data from the receiver of the communication group, after moving the data to be sent to the cache for receiving data, the receiver of the communication group is also informed through the doorbell that the data to be sent has been moved to the cache for receiving data; in response to receiving the doorbell, the receiver of the communication group recognizes that the data to be sent already exists in the cache for receiving data.

[0028] A seventh method for implementing a message communication middleware in a subscription and publication communication mode according to the second aspect of the present application is provided, wherein the sender of the communication group responds to receiving a doorbell by also writing a response tag at a specified address, and the receiver of the communication group identifies that the sender of the communication group has successfully responded to the doorbell by reading the response tag; and / or the receiver of the communication group responds to receiving the doorbell by also writing a response tag at a specified address, and the sender of the communication group identifies that the receiver of the communication group has successfully responded to the doorbell by reading the response tag.

[0029] An eighth message communication middleware method for implementing a subscription and publication communication mode according to the second aspect of the present application is provided, wherein, in response to the communication interface haos_i_send() being called, parameters representing a communication group and parameters representing data to be sent are obtained from the communication interface, and the call to the communication interface haos_i_send() is returned; the master member of the communication group that calls the communication interface haos_i_send() informs the slave members of the communication group that it has called the communication interface haos_i_send(), and informs the data cache address of the data to be sent; in response to the communication interface haos_i_recv() being called, parameters representing the communication group and parameters representing a data cache for receiving data are obtained from the communication interface, and the call to the communication interface haos_i_recv() is returned; calling the communication interface haos_i_send() The slave member of the communication group that has called os_i_recv() determines whether the master member of the communication group has called the communication interface haos_i_send(); if the master member of the communication group has called the communication interface haos_i_send(), moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data; in response to receiving the data to be sent from the master member of the communication group, marks the communication process corresponding to the communication interface haos_i_recv() as completed, and informs the master member of the communication group that it has received the data to be sent; in response to the slave member of the communication group having received the data to be sent, the master member of the communication group that has called the communication interface haos_i_send() marks the communication process corresponding to the communication interface haos_i_send() as completed.

[0030] A ninth method of a message communication middleware for implementing a subscription and publication communication mode according to the second aspect of the present application is provided, wherein a slave member of the communication group that calls the communication interface haos_i_recv() marks itself ready to receive data if it determines that the master member of the communication group has not yet called the communication interface haos_i_send(); in response to the master member of the communication group informing the slave members of the communication group that it has called the communication interface haos_i_send(), the communication group that calls the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data.

[0031] According to the fourth aspect of the present application, a method for performing message communication using a subscription and publication communication mode between nodes of a Feiteng FT-6678N multi-processor distributed parallel computing system according to the fifth aspect of the present application is provided, wherein the Feiteng FT-6678N multi-processor distributed parallel computing system includes multiple nodes interconnected by SRIO, each of the nodes runs a message communication middleware, and the multiple interconnected nodes include a first node and a second node; the message communication middleware is used to execute the method according to the fourth aspect of the present application; the method for performing message communication using the subscription and publication communication mode includes: the first node calls the communication interface haos_i_publish() to publish a specified topic, wherein the communication interface haos_i_publish() carries parameters representing the topic; the second node calls the communication interface haos_i_subscribe() to subscribe to a specified topic, wherein the communication interface haos_i_subscribe() carries parameters representing the topic; the first node treats the message to be sent to the second node as a message published on the specified topic; the second node receives the message to be sent by the first node to the second node from the specified topic.

[0032] According to the second method of the fourth aspect of the present application, a message communication is performed between nodes based on the Feiteng FT-6678N multi-processor distributed parallel computing system using a subscription and publication communication mode, wherein a first node calls a communication interface haos_i_send() to publish a message on a specified topic through a subscription and publication communication mode, wherein the communication interface haos_i_send() carries parameters representing a specified topic and parameters representing a message to be published, and the parameters representing the specified topic are associated with a communication group used for the communication interface haos_i_send(); a second node calls a communication interface haos_i_recv() to receive a message from a specified topic, wherein the communication interface haos_i_recv() carries parameters representing a specified topic and parameters representing a cache of messages to be received, and the parameters representing the specified topic are associated with a communication group used for the communication interface haos_i_recv().

[0033] According to the third method of the fourth aspect of the present application, a method for message communication between nodes based on the Feiteng FT-6678N multi-processor distributed parallel computing system using the subscription and publication communication mode also includes: one or more third nodes call the communication interface haos_i_subscribe() to subscribe to a specified topic, wherein the communication interface haos_i_subscribe() carries parameters representing the topic; the first node sends the message to the second node and one or more third nodes as a message published on the specified topic through the subscription and publication communication mode; one or more third nodes receive the message that the first node wants to send to the second node and one or more third nodes from the specified topic through the subscription and publication communication mode; each third node calls the communication interface haos_i_recv() to receive a message from the specified topic.

[0034] According to the fourth aspect of the fourth application, a method for message communication using a subscription and publication communication mode is provided between nodes based on a Feiteng FT-6678N multi-processor distributed parallel computing system, wherein: a first node repeatedly calls the communication interface haos_i_send() to publish multiple messages on a specified topic through the subscription and publication communication mode; a second node repeatedly calls the communication interface haos_i_recv() to receive multiple messages from the specified topic.

[0035] According to the fifth aspect of the present application, a computing device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, one of the methods provided in the first to fourth aspects of the present application is implemented.

[0036] The positive technical effects of this application are:

[0037] The message communication middleware in the multi-processor distributed parallel computing system based on Feiteng FT-6678N is located between the application and the operating system, shielding the operating details of the operating system and hardware drivers, so that users do not need to understand the details and heterogeneity of the internal data link and link protocol, and provides a unified service for data transmission between nodes or tasks (processes or threads) on nodes. No matter which processor, node, or physical location the task is located on, no matter what communication technology (Ethernet, SRIO, shared memory, etc.) is used. The application calls the interface provided by the message communication middleware to achieve communication and synchronization without worrying about any details of the underlying layer. As a result, the application running on a node of the system can be easily or directly migrated to other nodes without modifying the application.

[0038] Based on the application program in the multi-processor distributed parallel computing system of Feiteng FT-6678N, the message middleware according to the embodiment of the present application is used to process the distributed signal processing tasks in the processing mode of the software pipeline. Compared with the serial communication method, the performance can be improved by 3 times. Since the message communication middleware provides a non-blocking communication mode, the three beats (data reception, signal processing calculation and data transmission) belonging to different task stages in a task processing cycle of each node of the software pipeline can be processed in parallel, and the processing time of the signal processing calculation beat, the data reception beat and the data transmission beat can overlap, so that the processing of the adjacent three beats in a task processing cycle is completed within the processing time of a single beat. Thus, the processing time in a task processing cycle is shortened to 1 / 3 of the original, and the overall task processing performance is improved to 3 times of the original. Thus, the overall performance is improved. It can be understood that the above performance analysis is based on the assumption that the three beats (data reception, signal processing calculation and data transmission) each take roughly the same time. When the three beats each take different time, the performance improvement value is different.

[0039] An application program in a multi-processor distributed parallel computing system based on Feiteng FT-6678N can also perform message communication based on a subscription and publication communication mode by utilizing the message middleware according to an embodiment of the present application, without having to worry about the physical information of the message sender / receiver or the timing of sending / receiving messages. Furthermore, the message sending / receiving operation will neither affect the behavior of the other end of the message communication nor block other data processing of the message sender / receiver itself.

[0040] The message communication middleware in the multi-processor distributed parallel computing system based on Feiteng FT-6678N implements the subscription and publication communication mode on the SRIO link. The application realizes the message communication between applications located in different FT-6678N nodes by publishing and subscribing to the specified topics, and publishing and receiving messages on the subscribed topics. The message communication between different FT-6678N nodes only needs to describe the topic to which the message belongs to communicate, without knowing and processing the physical information related to the sender / receiver of the message, and without processing the order of message sending and receiving. In addition, the message communication based on the subscription and publication mode can be non-blocking. After initiating the message sending / receiving, the node application can process other computing tasks in parallel without being blocked by the message communication. The message communication sending of one node will not be blocked by the message receiving process of another node. This simplifies the code complexity of the message communication between different FT-6678N nodes of the application, and improves the data processing and communication efficiency of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0042] Figure 1 A block diagram of a multi-processor distributed parallel computing system based on Feiteng FT-6678N according to an embodiment of the present application is shown.

[0043] Figure 2 A schematic diagram of a member discovery process of a communication group according to an embodiment of the present application is shown.

[0044] Figure 3 A schematic diagram showing a scenario in which a master member sends data and a slave member receives data, and the slave member operates first and then the master member operates according to an embodiment of the present application.

[0045] Figure 4 A schematic diagram showing a scenario in which a master member sends data and a slave member receives data according to an embodiment of the present application, and the master member operates first and the slave member operates later.

[0046] Figure 5 A schematic diagram showing a scenario in which a slave member sends data and a master member receives data, and the slave member operates first and the master member operates later according to an embodiment of the present application.

[0047] Figure 6 A schematic diagram showing a scenario in which a slave member sends data and a master member receives data, and the master member operates first and then the slave member operates according to an embodiment of the present application.

[0048] Fig. 7A A schematic diagram of an application framework of a node using a message communication middleware according to an embodiment of the present application is shown.

[0049] Figure 7B A schematic diagram showing the processing of the first three beats of the task processing cycle of node 720.

[0050] Figure 7C A schematic diagram showing the processing status of the second group of 3 beats of the task processing cycle of node 720.

[0051] Fig. 8A Shown Figure 7A-7C Schematic diagram of the processing process of the software pipeline formed by the three nodes in .

[0052] Figure 8B Shown Figure 7A-7C Schematic diagram of the processing process of the task processing cycle of the middle node 720.

[0053] Fig. 9A and Fig. 9B A schematic diagram showing a topic discovery process in a subscription and publication communication mode according to an embodiment of the present application.

[0054] Fig. 10A and Fig. 10B A schematic diagram showing a topic discovery process in a subscription and publication communication mode according to yet another embodiment of the present application.

[0055] Fig.11 The message communication process of the subscription and publication communication mode according to another embodiment of the present application is demonstrated. DETAILED DESCRIPTION

[0056] The following is a clear and complete description of the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0057] Figure 1 A block diagram of a multi-processor distributed parallel computing system based on Feiteng FT-6678N according to an embodiment of the present application is shown.

[0058] The provided distributed parallel computing system includes multiple nodes. Each node is a Feiteng FT-6678N processor running a program. Each node runs one or more application programs (such as application program 1, application program 2), an operating system, and a message communication middleware.

[0059] The application is, for example, a program developed by a user to perform underwater acoustic signal processing tasks. The middleware provides a variety of communication interfaces for the application, including, for example, haos_i_send(), haos_i_recv(), haos_i_scatter(), haos_i_gather(), haos_i_wait(), haos_i_test(), etc. These communication interfaces will be described in detail later. The application uses the message communication middleware of the embodiment of the present application to complete the communication between the nodes of the distributed computing system by calling these communication interfaces.

[0060] Optionally, an operating system is also run on the node. It is understandable that the operating system is not necessary, so that the message communication middleware and the application program directly run on the Feiteng FT-6678N processor.

[0061] The nodes based on the Feiteng FT-6678N processor are coupled to each other. Different nodes are coupled through, for example, Ethernet and SRIO links. The nodes also support EDMA transmission based on SRIO links, which can perform bulk data transmission between nodes independently of the CPU. The nodes can also communicate through other means such as shared memory (not shown).

[0062] Although Figure 1 A distributed parallel computing system including two nodes is shown in FIG. 1 . It can be understood that the distributed parallel computing system according to the embodiment of the present application may include other numbers of nodes.

[0063] Still optionally, multiple processes or threads located on the same Feiteng FT-6678N processor can also be used as nodes to use the message communication middleware according to the embodiment of the present application, although this will limit the parallel processing of three adjacent beats within a task processing cycle. Further optionally, the provided distributed parallel computing system may include a single Feiteng FT-6678N processor and multiple nodes running thereon.

[0064] The message communication middleware according to the embodiment of the present application performs communication between nodes based on the communication group. Since data transmission is established on at least two nodes, the data link network consisting of data transmission between two or more nodes is defined as a communication group, and the data communication form of "one-way multi-transmission" is called multicast (Scatter), and "multi-way one-transmission" is called gathering (Gather). The communication group does not directly provide support for the "multi-transmission and multi-reception" communication form.

[0065] A communication group includes multiple group members. The group members in a communication group consist of a master member and one or more slave members. The master member is responsible for establishing a communication group using a globally unique name. Optionally, the number of group members needs to be specified when establishing a communication group. Slave members join an established communication group using a unique name and assign themselves a group number when joining, and ensure that the number is globally unique. Setting the number ensures that multiple data received from different senders can be identified in the case of data aggregation.

[0066] In message communication middleware, point-to-point communication is a special case of group communication, that is, a communication group contains only two members, a master member and a slave member. In this case, multicast (Scatter) communication and gather (Gather) communication degenerate into point-to-point communication. Message communication middleware provides corresponding communication interfaces for different communication forms, thereby abstracting and unifying the concepts of several different forms of data communication. Different types of data communication services can be implemented using the same set of data sending and receiving interface functions.

[0067] For example, in the communication interface of the message communication middleware, haos_i_scatter() and haos_i_gather() are used for multicast communication and gathering communication respectively. And haos_i_send() and haos_i_recv() represent the sending operation and receiving operation in point-to-point communication respectively. Optionally, the application can only use the haos_i_scatter() and haos_i_gather() interfaces in the communication group, and the message communication middleware calls haos_i_send() and haos_i_recv() in the implementation of the haos_i_scatter() and haos_i_gather() interfaces according to the number of members of the communication group, so that multicast and gathering are implemented with multiple point-to-point sending operations and multiple point-to-point receiving operations respectively. Still optionally, the implementation of the haos_i_scatter() and haos_i_gather() interfaces does not depend on the haos_i_send() and haos_i_recv() interfaces.

[0068] The communication group encapsulates the sender and receiver of the process, so that the application only needs to identify the parties involved in the communication and their roles (sender or receiver) in the communication process by the name of the communication group, without knowing the physical address, network address, SRIO ID and other information of each party. It also simplifies the migration process of the application. When changing the running node of the application, the communication process is still initiated by specifying the communication group, without reprogramming or configuring the application according to the physical information of the node. Communication groups can be created and deleted dynamically. And the sender / receiver in the communication group does not need to correspond to the node one by one. The application on the node can belong to multiple communication groups at the same time, and multiple applications on the node can belong to the same communication group at the same time. The message communication middleware maintains the physical information of each sender / receiver in the communication group, and the physical information includes information such as physical address, network address, SRIO ID, etc.

[0069] The message communication middleware according to the embodiment of the present application also provides non-blocking communication. Non-blocking communication is mainly used to overlap the processing of computing tasks and the communication process in time, so as to improve the efficiency of the entire program execution. The communication interfaces haos_i_send(), haos_i_recv(), haos_i_scatter(), and haos_i_gather() of the message communication middleware are all non-blocking. After the application calls the non-blocking communication interface, the corresponding communication process is initiated by the message communication middleware, and there is no need to wait for the communication process to be processed. The called non-blocking communication interface returns, so that the application continues to execute the code after the called non-blocking communication interface. At this time, the communication process corresponding to the non-blocking communication interface is processed by the message communication middleware, and the code executed by the application can be the code for processing computing tasks, so that the computing tasks and the communication process are executed concurrently, and the two overlap in time.

[0070] Optionally, the communication process corresponding to the non-blocking communication interface can be handed over to specific communication hardware (such as a DMA unit or a network device) to complete. While the communication hardware completes the communication process, the processor can execute code to handle the computing task, thus achieving the overlap of computing and communication, which can greatly improve the efficiency of program execution.

[0071] Since when the call of the non-blocking communication interface returns, the communication process is generally not completed. For non-blocking sending operations (haos_i_send() / haos_i_scatter()), the sending buffer must wait until the sending operation is completed before it can be released. Therefore, a new mechanism needs to be introduced to let the application know when the data has been successfully sent. Similarly, for non-blocking receiving operations (haos_i_recv() / haos_i_gather()), the return of the call of the non-blocking communication interface does not mean that the received data message has been received in full. It is necessary to wait until the data reception is completed before the data can be subsequently operated. Therefore, for blocking communication, only one function call is needed to complete all operations of data transmission, but for non-blocking communication, two function calls are generally required, first of all, the "start" of non-blocking communication, but starting does not mean the completion of data transmission. To ensure that the communication is completed, the communication interface associated with the non-blocking communication must also be called to obtain the state of the communication process to know whether the communication process has been processed. According to the message communication middleware of the embodiment of the present application, two function calls are also provided: non-blocking waiting function haos_wait() and non-blocking detection function haos_test() are used to achieve the above-mentioned goals. No matter which of the above non-blocking communication interfaces (haos_i_send() / haos_i_scatter() / haos_i_recv() / haos_i_gather()) is used, the non-blocking waiting function haos_wait() and the non-blocking detection function haos_test() can be used to wait for or detect the completion of the non-blocking communication initiated by the communication interface. These communication interfaces will be described in detail later.

[0072] Figure 2 A schematic diagram of a member discovery process of a communication group according to an embodiment of the present application is shown.

[0073] According to an embodiment of the present application, the member discovery process of the communication group can be initiated by the master member of the communication group or by the slave member. For a distributed computing system, each node processes tasks concurrently, so there is no unified execution order between the programs on each node. Node A may execute first, or node B may execute first, and either node A or node B may initiate the member discovery process of the communication group. Therefore, the implementation of the member discovery process needs to deal with the different situations caused by the above-mentioned execution order.

[0074] Figure 2In the figure, top to bottom represents the direction of time flow. "Master" represents the master member of the communication group. "Slave" represents the slave member of the communication group. The black vertical line represents the operation performed by the master thread, and the red vertical line represents the operation performed by the daemon thread. Optionally, the daemon thread is provided by the message communication middleware, and the main thread is part of the application. For example, the main thread runs in the address space of the application, and the code of the operation related to the discovery of the communication group members in the main thread is provided by the message middleware.

[0075] Figure 2 In the figure, the processing flow indicated by the thick solid arrow is actively initiated by the master member, and the processing flow indicated by the thin dashed arrow is actively initiated by the slave member. The initiation of the communication group member discovery process can be in response to the application calling a related interface function, such as an interface function for creating a communication group or an interface function for joining a communication group.

[0076] In one example, the primary member of the communication group actively initiates the communication group member discovery process. Figure 2 Indicated by the thick solid arrow in . For example, in response to an application that is a primary member of a communication group initiating a process, as a response, the primary member's main thread first sends out a UDP broadcast packet carrying the communication group name and the physical information of the member, so as to find a slave member in the system that is to join the communication group with the communication group name. After the slave member is started, the daemon thread continues to listen to the UDP broadcast packet in the network. In response to receiving a UDP broadcast packet representing the communication group member discovery process, and when the communication group name carried by the UDP broadcast packet is consistent with the communication group name to be joined as recorded by itself, the daemon thread of the slave member adds the primary member to the communication group, and the daemon thread of the slave member replies to a UDP unicast message to the primary member that sent the UDP broadcast packet. If the communication group name carried by the UDP broadcast packet is inconsistent with the communication group name to be joined as recorded by itself, the daemon thread of the slave member does not respond to the UDP broadcast packet. Carry physical information of, for example, a slave member in the UDP unicast message. In response to receiving a UDP unicast message, the primary member obtains the physical information of the slave member indicated by the UDP message and adds the slave member to the communication group.

[0077] After the communication group is started by a slave member, it will also actively initiate the communication group member discovery process. Optionally, after the slave member is started, if it finds that it has received the UDP broadcast packet from the master member, and the communication group specified by the UDP broadcast packet is consistent with the communication group it wants to join, the slave member may not perform the operations required to initiate the communication group member discovery process itself.

[0078] Optionally, the communication group has multiple slave members, and each slave member replies with a UDP unicast message after receiving the UDP broadcast packet. Still optionally, after collecting all UDP unicast messages sent by the slave members, the master member also sends another UDP broadcast packet to end the communication group member discovery process. Still optionally, the master member daemon thread also notifies the master member's main thread to end the communication group member discovery process.

[0079] In another example, a slave member of the communication group actively initiates the communication group member discovery process, by Figure 2 Indicated by the thin dotted arrow in . The main thread of the slave member first sends out a UDP broadcast packet carrying the communication group name and the physical information of this member, so as to find the master member of the communication group with the communication group name in the system. After the master member is started, the daemon thread continues to listen to the UDP broadcast packets in the network. In response to the receipt of a UDP broadcast packet representing the communication group member discovery process of the master member, and when the communication group name carried by the UDP broadcast packet is consistent with the communication group name recorded by itself, the master member daemon thread will send the slave member of the UDP broadcast packet to join the communication group, and also reply a UDP unicast message to the slave member. If the communication group name carried by the UDP broadcast packet is inconsistent with the communication group name recorded by the master member itself, the master member daemon thread will not respond to the UDP broadcast packet, nor will it add the slave member to the communication group. The UDP unicast message replied by the master member of the communication group carries, for example, the physical information of the master member (IP address, SRIO ID, communication group name, etc.). In response to receiving the message, the daemon thread of the slave member adds the master member to the communication group and sends an end event to the master thread of the slave member. After receiving the end event, the master thread of the slave member stops sending UDP broadcast packets and ends the communication group member discovery process.

[0080] Optionally, receiving a UDP broadcast packet representing the communication group member discovery process from a slave member does not affect the master member's subsequent initiative to initiate the communication group member discovery process, and in the communication group member discovery process subsequently initiated by the master member, the slave member that has previously actively initiated the communication group member initiation process may no longer respond to the UDP broadcast packet representing the communication group member discovery process from the master member. The slave member that has actively initiated the communication group member initiation process may still respond to the UDP broadcast packet from the master member with a UDP unicast message.

[0081] If the master member or slave member that actively initiates the communication group member discovery process has not completed the discovery process, the master member or slave member will resend the UDP broadcast packet carrying the member information at a certain time interval within the agreed time to find other nodes in the communication group until the communication group member discovery process is completed.

[0082] After the communication group member discovery process is completed, the master member of the communication group records the physical information of all slave members of the communication group, and each slave member records the physical information of the master member of the communication group. Next, when the application of the master member wants to communicate through the communication group, it specifies the communication group when calling the communication interface. The message communication middleware of the node where the master member is located obtains the recorded physical information of each member of the communication group and handles the communication process. When the application of the slave member wants to communicate through the communication group, it specifies the communication group when calling the communication interface. The message communication middleware of the node where the slave member is located obtains the recorded physical information of the master member of the communication group and handles the communication process.

[0083] For example, the communication interface haos_i_send(hGroup,data) or haos_i_scatter(hGroup,data) is called to send data, and the communication interface haos_i_recv(hGroup,buf) or haos_i_gather(hGroup,buf) is called to receive data, where hGroup describes the communication group, data describes the data to be sent, and buf describes the buffer for receiving data. Optionally, the data to be sent can be described by the buffer for sending data. By using the communication group hGroup, there is no need to specifically specify the sender or receiver of the communication when calling the communication interface. Even if there are multiple senders / receivers (for haos_i_scatter and haos_i_gather), only the communication group is specified when calling the communication interface. The message communication middleware executes the communication process required to call the communication interface according to the role of each member in the communication group.

[0084] The communication interface haos_i_send() is a non-blocking function that uses non-blocking communication to send data to other members of the communication group. Its function is to start a non-blocking data sending operation. Regardless of whether the data sending is completed or not, the call to the communication interface haos_i_send() will return immediately. The return of the function call does not mean that the data has been successfully sent, but only means that the data can be sent.

[0085] The return value of the communication interface haos_i_send() can not only indicate whether the function is executed successfully, but also return a handle to describe the non-blocking communication status. This handle is hereinafter referred to as the "non-blocking communication object" handle. By querying the "non-blocking communication object", it can be determined whether the data communication initiated by the corresponding communication interface is completed.

[0086] The communication interface haos_i_send() is applicable to both point-to-point data transmission and one-to-many data transmission. In the point-to-point case, the sender simply sends a copy of the data to the only receiver; in the one-to-many case, the sender uses multicast to send the same copy of the data to each receiver.

[0087] The communication interface haos_i_recv() is also a non-blocking function, which uses non-blocking communication to receive data from other members of the communication group. Its function is to start a non-blocking data reception operation. Regardless of whether the data reception is completed or not, the call to the communication interface haos_i_recv() will return immediately. The return of the function call does not mean that the corresponding data has been received, but only means that the data that meets the requirements can be received. In addition to indicating whether the function execution is successful, the return value of the communication interface haos_i_recv() can also return a non-blocking communication object handle. By querying this object, it can be determined whether the non-blocking data reception initiated by the corresponding communication interface is completed.

[0088] The communication interface haos_i_recv() is applicable to point-to-point and many-to-one data receiving end situations. In both cases, the caller of the communication interface haos_i_recv() is on the "one" side and only receives one copy of the data.

[0089] The communication interface haos_wait() takes a non-blocking communication object as a parameter. After haos_wait() is called, it will not return until the non-blocking communication corresponding to the non-blocking communication object in the parameter is completed, and release the non-blocking communication object at the same time, so there is no need to explicitly release the object in the application. Calling haos_wait() may cause the current thread to be suspended and the system to switch threads.

[0090] The communication interface haos_test() also takes a non-blocking communication object as a parameter. After haos_test() is called, it returns to the current state of the non-blocking communication corresponding to the non-blocking communication object in the parameter. If the non-blocking communication has ended when haos_test() is called, haos_test() releases the non-blocking communication object while returning the communication completion flag, so there is no need to explicitly release this object in the application. If the non-blocking communication has not ended when haos_test() is called, haos_test() directly returns the unfinished flag and does not release the corresponding non-blocking communication object.

[0091] The message communication middleware according to the embodiment of the present application is applicable to nodes coupled via SRIO or EDMA (Enhanced Direct Memory Access).

[0092] Figure 3 A schematic diagram showing a scenario in which a master member sends data and a slave member receives data, and the slave member operates first and then the master member operates according to an embodiment of the present application.

[0093] The master member executes the communication process of sending data by calling, for example, haos_i_send(hGroup, data), while the slave member executes the communication process of receiving data by calling, for example, haos_i_recv(hGroup, buf). Since the master member and the slave member operate independently, the order in which they call the communication interface haos_i_send(hGroup, data) or haos_i_recv(hGroup, buf) cannot be determined. It is possible that the master member called haos_i_send(hGroup, data) first, and the slave member called haos_i_send(hGroup, data) later, or it may be similar. The message communication middleware according to the embodiment of the present application handles these different scenarios.

[0094] See also Figure 3 , two FT-6687N nodes (310 and 320) are coupled via SRIO or EDMA, and optionally, an Ethernet link is also included between the two nodes, and the message communication middleware according to the embodiment of the present application is used for communication. When the two nodes are coupled via SRIO, the nodes communicate via DIO (Direct IO) and doorbell. The node can write data directly into the memory of another node or directly read the memory of another node through DIO technology, and inform the other party through the doorbell that the data transmission is completed or the data is ready. When the two nodes are coupled via EDMA, the nodes communicate via shared memory and processor core interrupts.

[0095] FT-6687 node 310 is the master member of the communication group, and FT-6687 node 320 is the slave member of the communication group. The application of the slave member first calls the communication interface haos_i_recv() to try to receive data, and the application of the master member then calls the communication interface haos_i_send() to send data. Nodes 310 and 320 each run a main thread and a daemon thread. The daemon thread is provided by the message communication middleware, and the main thread can be provided by the message communication middleware, or it can be part of the application. Optionally, nodes 310 and 320 each run an operating system. The operating system is, for example, a lightweight embedded operating system. It can be understood that the operating system is not necessary, and the application and the message communication middleware can run directly on the FT-6687N node.

[0096] Regardless of whether the communication interface haos_i_send() / haos_i_recv() is called, the daemon thread is running and continuously listens for messages from other members of the communication group.

[0097] Figure 4 Figure 4 In response to a call to haos_i_recv() from a member's application Figure 3 The slave member also continues to monitor the network, waiting to receive data from the master member. The communication interface haos_i_recv() is non-blocking, so it returns immediately after being called, so that the main thread of the slave member continues to execute subsequent code. The slave member waits for data from the master member in the daemon thread. Optionally, the subsequent codes of the slave member main thread include calls to, for example, the communication interface haos_i_wait() ( Figure 3 (Indicated by (B) in the figure) is used to wait for the data receiving process corresponding to haos_i_recv(), or to call haos_i_test() to detect the current progress of the data receiving process corresponding to haos_i_recv().

[0098] Since the master member has not called haos_i_send(), after the master member background process receives the HAOS_SNDRDY packet sent by the slave member, it saves the relevant information of the HAOS_SNDRDY packet in the communication control data structure ( Figure 3 (indicated by (2)).

[0099] At some point in the next step, the master member calls haos_i_send()( Figure 3 In response to haos_i_send() being called, the message communication middleware obtains information such as the data receiver in the communication group and sends a HAOS_SNDRDY information packet to the slave member that is the receiver ( Figure 3 Indicated by (2) in the figure), the HAOS_SNDRDY packet carries the data cache address of the data to be sent at the master member. In this embodiment, the master member sends the HAOS_SNDRDY packet to the slave member only depending on haos_i_send() being called by the master member, without caring whether the slave member has called haos_i_recv().

[0100] The communication interface haos_i_send() is non-blocking, so it returns immediately after being called ( Figure 3(3) indicates that the main thread of the main member continues to execute subsequent codes. Optionally, the subsequent codes of the main thread of the main member include a call to, for example, the communication interface haos_i_wait() ( Figure 3 The (A) indicator is used to wait for the data sending process corresponding to haos_i_send() to be completed, or to call haos_i_test() to detect the current progress of the data sending process corresponding to haos_i_send().

[0101] The slave member's daemon thread responds to receiving a HAOS_SNDRDY packet from the master member ( Figure 3 (indicated by (3-1) in the figure), knowing that the master member has prepared the data to be sent, obtains the address of the data to be sent from the HAOS_SNDRDY information packet. Since the slave member has called haos_i_recv() at this time and has a data cache for receiving data, in response to receiving the HAOS_SNDRDY information packet, the slave member can immediately initiate data transfer from the master member to the slave member through SRIO or EDMA, and move the data to be sent in the master member's data cache to the slave member's data cache for receiving data ( Figure 3 After the data migration is completed, the daemon thread of the slave member also sends a HAOS_SNDOK packet to the master member ( Figure 3 Indicated by (3-3) in the figure), and sends an event to the main thread of the slave member to notify the main thread of the slave member that the data receiving process initiated by calling haos_i_recv() has been completed.

[0102] In response to receiving the HAOS_SNDOK information packet, the daemon thread of the master member knows that the slave member has completed the data migration, and sends an event to the master thread of the master member to notify the master thread of the master member that the data sending process initiated by calling haos_i_send() has been completed. Optionally, the end event allows the blocked haos_i_wait() to return. If the main thread does not call haos_i_wait(), the end event can be directly ignored by the main thread. And the main thread can also learn that the data sending process has been completed by calling haos_i_test().

[0103] Optionally, the communication group specified by calling haos_i_send() has one sender and multiple receivers. Each slave member as a receiver uses Figure 3The method shown is to receive data from a single sender. As the sender, the master member sends a HAOS_SNDRDY packet to each receiver after preparing the data to be sent, to notify the slave members to actively move the data, and wait for the HAOS_SNDOK packet from the slave members to identify whether each slave member has completed the data move. And after identifying that all receivers in the communication group have completed the data move, notify the main thread that the data sending process is completed.

[0104] Therefore, in SRIO or EDMA-based communications, when a slave member acts as a data receiver, after recognizing that the master member is ready to send data, it actively moves data from the master member's memory to the local memory without the need for the master member acting as the sender to move data.

[0105] Figure 4 A schematic diagram showing a scenario in which a master member sends data and a slave member receives data according to an embodiment of the present application, and the master member operates first and the slave member operates later.

[0106] The master member executes the communication process of sending data by calling, for example, haos_i_send(hGroup, data), and the slave member executes the communication process of receiving data by calling, for example, haos_i_recv(hGroup, buf).

[0107] See also Figure 4 , two FT-6687N nodes (430 and 440) are coupled via SRIO or EDMA, and optionally, an Ethernet link is also included between the two nodes. FT-6687 node 430 is the master member of the communication group, and FT-6687 node 440 is the slave member of the communication group. The application of the master member first calls the communication interface haos_i_send() to send data; the application of the slave member then calls the communication interface haos_i_recv() to receive data. The master member and the slave member each provide a data buffer, which is used to accommodate the data to be sent and the received data respectively.

[0108] Regardless of whether the communication interface haos_i_send() / haos_i_recv() is called, the daemon thread is running and continuously listens for messages from other members of the communication group.

[0109] In this embodiment, the main thread of the slave member implements data migration from the master member to the slave member, so the main thread directly knows that the data migration is completed without additional event transmission between the remote master thread and the daemon thread.

[0110] In response to the application of the main member calling haos_i_send(), the message communication middleware (for example, in the main thread) obtains the data to be sent and the communication group ( Figure 4 Indicated by (1) in the figure), a HAOS_SNDRDY information packet is sent to the receiving slave member of the communication group to indicate to the slave member that the master member is ready to send data. The HAOS_SNDRY data packet also carries the data cache address used to send data at the master member.

[0111] The communication interface haos_i_send() is non-blocking, so it returns immediately after being called ( Figure 4 (1) indicates in the figure), so that the main thread of the main member continues to execute the subsequent code. Optionally, the subsequent codes of the main thread of the main member include a call to, for example, the communication interface haos_i_wait() ( Figure 4 The (A) indicator is used to wait for the data sending process corresponding to haos_i_send() to be completed.

[0112] The HAOS_SNDRDY packet sent by the master member is monitored and received by the daemon thread of the slave member ( Figure 4 Indicated by (2) in the figure). In response, the daemon thread of the slave member updates the communication control data structure to record that the data to be sent in the communication group is ready, and the data cache address for sending data carried by the HAOS_SNDRDY packet. However, since the slave member has not called haos_i_recv() at this time, there is no available data cache for receiving data, so the slave member will not initiate data transfer from the master member to the slave member for the time being.

[0113] At some point later, haos_i_recv() is called from the member's application. Figure 4 In response to the slave member's application calling haos_i_recv(), the data cache for receiving data is obtained from the parameters of haos_i_recv(), and since the HAOS_SNDRDY information packet has been received, the slave member main thread can immediately initiate data movement from the master member's data cache to the slave member's data cache through SRIO or EDMA ( Figure 4 (indicated by (3-2)).

[0114] After the data migration is completed, the main thread of the slave member also sends a HAOS_SNDOK packet to the master member ( Figure 4 Indicated by (3-3)).

[0115] In response to receiving the HAOS_SNDOK information packet, the daemon thread of the master member knows that the slave member has completed the data migration, and sends an event to the master thread of the master member to notify the master thread of the master member that the data sending process initiated by calling haos_i_send() has been completed. Optionally, the end event allows the blocked haos_i_wait() to return. If the main thread does not call haos_i_wait(), the end event can be directly ignored by the main thread.

[0116] The communication interface haos_i_recv() is non-blocking. Figure 4 In the embodiment, when haos_i_recv() is called, the operations of moving data from the primary member and sending HAOS_SNDOK to the primary member can occur immediately. Therefore, haos_i_recv() can return after sending HAOS_SNDOK without significantly blocking the application that calls haos_i_recv() from the member.

[0117] Optionally, the communication group specified by calling haos_i_send() has one sender and multiple receivers. Each slave member as a receiver uses Figure 4 The method shown is to receive data from a single sender. As the sender, the master member sends a HAOS_SNDRDY packet to each receiver after haos_i_send() is called to instruct each receiver to move data from the master member's data cache. After the master member's daemon thread recognizes that all receivers in the communication group have moved data by listening to the HAOS_SNDOK packet, it notifies the master thread that the data sending process is complete.

[0118] Still optionally, in a communication process with one sender and multiple receivers in a communication group, some receivers may run before the sender and some receivers may run after the sender. For the processing of the receiver that runs before the sender after calling haos_i_recv(), see Figure 3 , and the receiver that runs later than the sender will see the processing after calling haos_i_recv(). Figure 4 For the master member, a HAOS_SNDRDY packet is sent to each receiver to instruct each receiver to move data from the master member's data cache. After the master member's daemon thread recognizes that all receivers in the communication group have moved data by monitoring the HAOS_SNDOK packet, it notifies the master thread that the data sending process has been completed.

[0119] In yet another embodiment, the master member calls haos_i_scatter() to send data to the slave member, and the slave member calls haos_i_recv() to receive data.

[0120] haos_i_scatter() is a non-blocking function, representing the group communication process from "one" to "many". The master member of the communication group uses non-blocking communication to distribute data to all slave members by calling haos_i_scatter(). Its function is to start a non-blocking data distribution operation. Regardless of whether the data distribution operation is completed or not, the call to haos_i_scatter() will return immediately. The function return does not mean that the data has been successfully distributed, but only that the data can be distributed. In addition to indicating whether the function is executed successfully, the return value of haos_i_scatter() can also return a non-blocking communication object handle. By querying this object, it can be determined whether the corresponding non-blocking data distribution is completed.

[0121] haos_i_scatter() is suitable for one-to-many data distribution. The difference between haos_i_send() and haos_i_scatter() is that when using haos_i_scatter(), the content and length of the data sent by the master member of the communication group to each slave member can be different.

[0122] The master member's message communication middleware implements haos_i_scatter() in the same way Figure 3-4 The implementation of haos_i_send() is similar to that shown in , with the difference that the data sent to each slave member can be specified independently, so that the content / length of the data can be different.

[0123] The message communication middleware according to the embodiment of the present application also supports the scenario where the slave member of the communication group sends data and the master member receives data. The slave member sends data to the communication group by calling haos_i_send(), and the master member receives data by calling haos_i_recv().

[0124] Figure 5 A schematic diagram showing a scenario in which a slave member sends data, a master member receives data, and the slave member operates first and then the master member operates according to an embodiment of the present application.

[0125] The slave member executes the communication process of sending data by calling, for example, haos_i_send(hGroup, data), while the master member executes the communication process of receiving data by calling, for example, haos_i_recv(hGroup, buf). Since the master member and the slave member operate independently, the order in which they call the communication interface haos_i_send(hGroup, data) or haos_i_recv(hGroup, buf) cannot be determined. It is possible that the slave member called haos_i_send(hGroup, data) first, and the master member called haos_i_send(hGroup, data) later, or it may be the other way around. The message communication middleware according to the embodiment of the present application handles these different scenarios.

[0126] See also Figure 5 , two FT-6687N nodes (510 and 520) are coupled via SRIO or EDMA and communicate using the message communication middleware according to the embodiment of the present application.

[0127] FT-6687 node 510 is the master member of the communication group, and FT-6687 node 520 is the slave member of the communication group. The slave member's application first calls the communication interface haos_i_send() to send data, and the master member's application then calls the communication interface haos_i_recv() to receive data. Nodes 510 and 520 run the main thread and the daemon thread respectively.

[0128] Regardless of whether the communication interface haos_i_send() / haos_i_recv() is called, the daemon thread is running and continuously listens for messages from other members of the communication group.

[0129] 66 In response to a call to haos_i_send() from a member's application Figure 5 (indicated by (1) in the figure), the message communication middleware obtains the communication group specified in the parameters and the data cache for sending data. The slave member main thread sends a HAOS_SNDRDY information packet to the master member of the communication group to inform the master member that the data to be sent is ready. The slave member also continues to monitor the network, waiting to receive data from the master member. The communication interface haos_i_send() is non-blocking, so it returns immediately after being called without waiting for the data transfer to the master member to be initiated or completed, so that the main thread of the slave member continues to execute subsequent code. Optionally, the subsequent codes of the slave member main thread include calls to, for example, communication interface haos_i_wait() ( Figure 5 The (B) indicator is used to wait for the data sending process corresponding to haos_i_send() to be completed.

[0130] At this time, the master member has not yet called haos_i_recv(). After the background process of the master member receives the HAOS_SNDRDY packet sent by the slave member, it saves the relevant information of the HAOS_SNDRDY packet in the communication control data structure ( Figure 5 (indicated by (2)).

[0131] At some point in the next step, the master member calls haos_i_recv()( Figure 5 In response to haos_i_recv() being called and having received the HAOS_SNDRDY packet from the slave member, the message communication middleware obtains information such as the data receiver in the communication group and sends a HAOS_RCV_RDY packet to the slave member as the sender ( Figure 5 (Indicated by (3-1) in FIG. 1 ), the HAOS_RCV_RDY packet is used to inform the slave member that the master member is ready to receive data, and carries the data cache address for receiving data at the master member.

[0132] The communication interface haos_i_recv() is non-blocking, so it returns immediately after being called, so that the main thread of the master member continues to execute subsequent codes. The master member waits for data from the slave member in the daemon thread. Optionally, the subsequent codes of the main thread of the master member include calls to, for example, the communication interface haos_i_wait() ( Figure 5 (A) is used to wait for the data receiving process corresponding to haos_i_recv().

[0133] In response to the master member as the receiver calling the communication interface haos_i_recv(), a HAOS_RCV_RDY packet is sent to the slave member as the sender. The HAOS_RCV_RDY packet carries the data buffer address for receiving data and the length of the data to be received. Then the called communication interface haos_i_recv() returns immediately.

[0134] The slave member's daemon thread responds to receiving a HAOS_RCV_RDY packet from the master member ( Figure 5 (4-1) indicates in the figure), knowing that the master member is ready to receive data, obtains the data cache address of the data to be received from the HAOS_SNDRDY information packet. Since the slave member has called haos_i_send() at this time and has data to send, in response to receiving the HAOS_RCV_RDY information packet, the slave member can immediately initiate data movement from its own data cache to the master member's data cache for receiving data through SRIO or EDMA, and move the data to be sent in the slave member's data cache to the master member's data cache for receiving data ( Figure 5 After the data is moved, the slave member's daemon thread also sends a HAOS_SNDOK packet to the master member (indicated by (4-2) in the example above). Figure 5 Indicated by (4-3) in the figure), and sends an event to the main thread of the slave member to notify the main thread of the slave member that the data sending process initiated by calling haos_i_send() has been completed.

[0135] In response to receiving the HAOS_SNDOK information packet, the daemon thread of the master member knows that the slave member has completed the data migration, and sends an event to the master thread of the master member to notify the master thread of the master member that the data sending process initiated by calling haos_i_recv() has been processed ( Figure 5 Optionally, the end event allows the blocked haos_i_wait() to return. If the main thread does not call haos_i_wait(), the end event can be directly ignored by the main thread.

[0136] Therefore, in SRIO or EDMA-based communications, when a slave member acts as a data sender, after recognizing that the master member is ready to receive data, it actively moves the data in the local memory to the master member's memory, without the need for the master member acting as the sender to move the data.

[0137] Figure 6 A schematic diagram showing a scenario in which a slave member sends data, a master member receives data, and the master member operates first and then the slave member operates according to an embodiment of the present application.

[0138] The master member performs a communication process of receiving data by calling, for example, haos_i_recv(hGroup, data), and the slave member performs a communication process of sending data by calling, for example, haos_i_send(hGroup, buf).

[0139] See also Figure 6 , two FT-6687N nodes (630 and 640) are coupled via SRIO or EDMA. FT-6687 node 630 is the master member of the communication group, and FT-6687 node 640 is the slave member of the communication group. The application of the master member first calls the communication interface haos_i_recv() to receive data; the application of the slave member then calls the communication interface haos_i_send() to send data. The master member and the slave member each provide a data buffer, which is used to accommodate the data to be sent and the received data respectively.

[0140] Regardless of whether the communication interface haos_i_send() / haos_i_recv() is called, the daemon thread is running and continuously listens for messages from other members of the communication group.

[0141] In response to the application of the main member calling haos_i_recv(), the message communication middleware (for example, in the main thread) obtains the data to be sent and the communication group ( Figure 6 Indicated by (1) in the figure), check whether the HAOS_SNDRDY packet has been received from the slave member of the communication group. Figure 6 In the example, at this time, the slave member has not called haos_i_send() and has not sent the HAOS_SNDRDY packet, so the daemon thread of the master member listens to the data from the slave member and does not send the HAOS_RCV_RDY packet yet.

[0142] The communication interface haos_i_recv() is non-blocking, so it returns immediately after being called ( Figure 6 (1) indicates in the figure), so that the main thread of the main member continues to execute the subsequent code. Optionally, the subsequent codes of the main thread of the main member include a call to, for example, the communication interface haos_i_wait() ( Figure 6 The (A) indicator is used to wait for the data sending process corresponding to haos_i_send() to be completed.

[0143] At some point later, haos_i_send() is called from the member's application. Figure 6 Indicated by (2) in the figure). In response to the application of the slave member calling haos_i_send(), the data to be sent and the communication group are obtained from the parameters of haos_i_send(), and a HAOS_SNDRDY packet is sent to the master member of the communication group to indicate to the master member that the slave member is ready to send data. The communication interface haos_i_send() is non-blocking, so it returns immediately after being called without waiting for the data transfer to the master member to be initiated or completed, so that the main thread of the slave member continues to execute subsequent code. Optionally, the subsequent codes of the slave member main thread include calls to, for example, the communication interface haos_i_wait() ( Figure 6 The (B) indicator is used to wait for the data sending process corresponding to haos_i_send() to be completed.

[0144] The HAOS_SNDRDY packet sent from the member is monitored and received by the daemon thread of the master member ( Figure 6In response, the daemon thread of the master member updates the communication control data structure to record that the data to be sent in the communication group is ready. The daemon thread of the master member also obtains from the communication control data structure that the master member has called haos_i_recv(), and the data buffer required for receiving data is ready and can receive data. Therefore, the daemon thread of the master member also sends a HAOS_REV_RDY information packet to the slave member ( Figure 4 (Indicated by (3-1)), the HAOS_REV_RDY information packet carries the data cache address of the primary member for receiving data.

[0145] In response to receiving the HAOS_RCV_RDY packet from the master member (indicated by (4-1) in FIG. CA), the daemon thread of the slave member knows that the master member is ready to receive data, and obtains the data cache address of the data to be received from the HAOS_SNDRDY packet. Since the slave member has called haos_i_send() at this time and has the data to be sent, in response to receiving the HAOS_RCV_RDY packet, the slave member can immediately initiate data movement from its own data cache to the master member's data cache pair for receiving data through SRIO or EDMA, and move the data to be sent in the slave member's data cache to the master member's data cache for receiving data ( Figure 6 After the data migration is completed, the daemon thread of the slave member also sends a HAOS_SNDOK packet to the master member ( Figure 6 Indicated by (4-3) in the figure), and sends an event to the main thread of the slave member to notify the main thread of the slave member that the data sending process initiated by calling haos_i_send() has been completed.

[0146] In response to receiving the HAOS_SNDOK information packet, the daemon thread of the master member knows that the slave member has completed the data migration, and sends an event to the master thread of the master member to notify the master thread of the master member that the data sending process initiated by calling haos_i_recv() has been processed ( Figure 5 Optionally, the end event causes the blocked haos_i_wait() to return.

[0147] Optionally, the communication group specified by calling haos_i_recv() has multiple senders and one receiver. Figure 5 or Figure 6The data is sent to a single receiver in the displayed manner. As the master member of the receiver, when it is ready to receive data and receives the HAOS_SNDRYD packet from the sender, it sends a HAOS_RCV_RDY packet to each sender to notify the slave members to actively move the data, and waits for the HAOS_SNDOK packet from the slave members to identify whether each slave member has completed the data move.

[0148] Still optionally, in a communication process with multiple senders and one receiver in a communication group, some senders may run before the receiver, and some senders may run after the receiver. For the processing of the sender that runs before the receiver after calling haos_i_send(), see Figure 5 , and the sender that runs later than the receiver will see the processing after calling haos_i_send(). Figure 6 For the master member, after calling haos_i_recv(), it sends a HAOS_REV_RDY packet to each sender that has sent a HAOS_SNDRDY packet, instructing each sender to move data to the master member's data cache. And after the master member's daemon thread recognizes that all senders in the communication group have moved data by listening to the HAOS_SNDOK packet, it notifies the master thread that the data sending process has been completed.

[0149] In yet another embodiment, the master member calls haos_i_gather() to receive data from the slave members, and the slave members call haos_i_send() to send data.

[0150] haos_i_gather() is a non-blocking function, representing the group communication process from "many" to "one". The master member of the communication group gathers data from all slave members using non-blocking communication by calling haos_i_gather(). Its function is to start a non-blocking data gathering operation. Regardless of whether the data gathering operation is completed or not, the call to haos_i_gather() will return immediately. The function return does not mean that the data gathering has been successfully completed, but only means that the data that meets the requirements can be gathered. In addition to indicating whether the function execution is successful, the return value of haos_i_gather() can also return the non-blocking communication object handle. By querying this object, it can be determined whether the corresponding non-blocking data gathering is completed.

[0151] haos_i_gather() is suitable for many-to-one data aggregation, where data from different sources are transferred to their respective specified data caches.

[0152] The main member's message communication middleware implements haos_i_gather() in the same way Figure 5-6haos_i_recv() is implemented in a similar way as shown in .

[0153] When using the blocking communication mode, the application program of each node of the multi-processor distributed parallel computing system based on Feiteng FT-6678N first receives data from the upstream node and stores it in the input buffer area; then uses the received data as input data for signal processing calculation, and writes the result to the output buffer area; finally, sends the data in the output buffer area to the downstream node. However, when the message communication middleware provided according to the embodiment of the present application is used with a non-blocking communication mode, the application program cannot use such a processing flow. Because when using the message communication middleware according to the embodiment of the present application, the data receiving operation (such as haos_i_recv()) and the sending operation (such as haos_i_send()) are returned immediately, in most cases, the data has not been received or sent yet. The code of the signal processing calculation after the data receiving operation / before the data sending operation will be executed, and the signal processing calculation will be performed using the same buffer area, which will conflict with the data transmission operation and destroy the integrity and consistency of the data. To solve this problem, according to the embodiment of the present application, an application framework for nodes using the message communication middleware is also provided.

[0154] Fig. 7A A schematic diagram of an application framework of a node using a message communication middleware according to an embodiment of the present application is shown.

[0155] Fig. 7A In the example, the multi-processor distributed parallel computing system based on Feiteng FT-6678N includes three nodes (node ​​710, node 720 and node 730). Each node runs an application to collaborate on parallel computing. Node 710 and node 720 join communication group G0. In node G0, node 710 sends data to node 720. Node 720 and node 730 join communication group G1. Node 720 sends data to node 730. Fig. 7A In the example, since there are only two members in the communication group, any one of the members can be the master member and the other member can be the slave member.

[0156] In order to facilitate the parallel execution of data communication and data processing calculation, taking node 720 as an example, the node's application uses two inbound caches (inbound cache A and inbound cache B of node 720) and two outbound caches (outbound cache A and outbound cache B of node 720). The data processing part code of the node's application (referred to as data processing module for short) uses one inbound cache and one outbound cache to perform data processing calculations, but does not use another inbound cache and another outbound cache. When the data processing module is working, the other inbound cache is used to process the communication process of receiving data in communication group G0, and the other outbound cache is used to process the communication process of sending data in communication group G1.

[0157] The interface form of the data processing module is, for example, void process (void *pInBuf, void *pOutBuf), where process represents the function name, and the parameter *pInBuf represents an inbound buffer, and the parameter *pOutBuf represents an outbound buffer. The data processing module is set by calling process (*pInBuf, *pOutBuf) in the application.

[0158] The task processing loop in the application framework of node 720 includes 6 beats belonging to different task stages. The 6 beats are divided into two groups, front and back. Each group includes 3 beats, namely data receiving beat, data processing calculation beat and data sending beat.

[0159] The three beats in each group are initiated concurrently, so that the cache resources used by the three beats cannot conflict. Fig. 7A In the first three beats of the task processing cycle of node 720, the data sending beat uses the outbound buffer B, the data receiving beat uses the inbound buffer B, and the data processing beat uses the inbound buffer A and the outbound buffer A. The inbound buffer A can provide input data for the data processing module, and the outbound buffer A can be used to accommodate the output data calculated by the data processing module. The first three beats are expressed in pseudo code as follows:

[0160] haos_i_send(hGroup_1,pOutBuf_B);

[0161] haos_i_recv(hGroup_0,pInBuf_B);

[0162] process(pInBuf_A,pOutBuf_A);

[0163] Among them, hGroup_1 represents the communication group G1, hGroup_0 represents the communication group G0, pOutBuf_B represents the outbound buffer B, pInBuf_B represents the inbound buffer B, pInBuf_A represents the inbound buffer A, and pOutBuf_A represents the outbound buffer A.

[0164] It should be understood that although the three lines of pseudo code with a sequential order are listed above, the communication interfaces haos_i_send() and haos_i_recv() according to the embodiment of the present application are non-blocking, and thus they return immediately after being called. haos_i_send initiates the data sending beat, haos_i_recv() initiates the data receiving beat, and both the data sending beat and the data receiving beat are processed in the background, so that their processing can be carried out in parallel with the data processing beat represented by process() without serial processing. Thus, the processing of the data sending beat, the data receiving beat and the data processing beat overlaps in time, shortening the overall time required to process the three beats.

[0165] According to the embodiment of the present application, process() is blocked, and the function returns only after the processing is completed, and the application will continue to execute subsequent codes. At this time, the output data generated by the data processing beat represented by process() is located in the outbound cache A, and it does not need to use the inbound cache A anymore. Thus, next, the data movement from the outbound cache A of node 720 to the node 730, and the data movement from the node 710 to the inbound cache A can be initiated. However, the processing time of each of the three beats is uncertain. After process() is completed, the processing of the data sending beat and / or the data receiving beat may not be completed. For this reason, after the first group of three beats, it is necessary to detect or wait for the data sending beat and the data receiving beat to be processed. For example, haos_wait (nSendReq) and haos_wait (nRecvReq) can be used to wait for the data sending beat and the data receiving beat to be processed. After the data sending beat and the data receiving beat are processed, the corresponding haos_wait () function call returns, and the application is able to process the subsequent code. The parameter nSendReq is a non-blocking communication object handle for haos_i_send(), and the parameter nRecvReq is a non-blocking communication object handle for haos_i_recv(). Optionally, haos_i_test() is used to replace haos_i_wait(). For example, the code while(1!=haos_test(nSendReq)||1!=haos_test(nRecvReq)) is used to wait for both the data sending beat and the data receiving beat to be processed.

[0166] In the application of node 720, the second group of 3 beats of the task processing loop is processed next. In the second group of 3 beats, the inbound buffer and the outbound buffer used are swapped compared with the first group. As an example, the second group of 3 beats is represented by pseudo code as follows:

[0167] haos_i_send(hGroup_1,pOutBuf_A);

[0168] haos_i_recv(hGroup_0,pInBuf_A);

[0169] process(pInBuf_B,pOutBuf_B);

[0170] It means that in the second group of three beats, the data sending beat uses the outbound buffer A, the data receiving beat uses the inbound buffer A, and the data processing beat uses the inbound buffer B and the outbound buffer B. The inbound buffer B can provide input data for the data processing module, and the outbound buffer B can be used to accommodate the output data calculated by the data processing module. Therefore, in the two beat groups, the two data sending beats use different outbound buffers, the two data receiving beats use different inbound buffers, and the two data processing beats use different inbound and outbound buffers. And within a beat group, the inbound buffer and outbound buffer used by the data processing beat are different from the inbound buffer and outbound buffer used by the data sending beat and the data receiving beat.

[0171] The three beats in the second group are also processed in parallel, so that the processing of the data sending beat, the data receiving beat and the data processing beat overlaps in time, shortening the overall time required to process the three beats. After the second group of three beats, it is also necessary to detect or wait for the data sending beat and the data receiving beat to be processed. After all three beats in the second group are processed, a task processing cycle is completed.

[0172] The application 720 continues to work by repeatedly executing a task processing cycle.

[0173] The application programs on the nodes 710 and 730 may have the same or similar structure as the application program on the node 720, so that these nodes form a software pipeline to collaboratively process tasks. Each node performs another stage of task processing based on the data processed and output by the previous node, and the task processing of each node may occur in parallel, and the task processing and communication process of each node may also occur in parallel, thereby improving the overall performance.

[0174] It should be understood that in the first group of three beats of the task processing cycle of node 720, the data receiving beat corresponds to the data sending beat of its previous node (node ​​710) (occurring at the same time and belonging to the same data communication process of the same communication group). In the first group of three beats of the task processing cycle of node 720, the data sending beat corresponds to the data sending beat of its subsequent node (node ​​730). Similarly, in the second group of three beats of the task processing cycle of node 720, the data receiving beat corresponds to the data sending beat of its previous node (node ​​710), and the data sending beat corresponds to the data sending beat of its subsequent node (node ​​730).

[0175] Figure 7B A schematic diagram showing the processing of the first three beats of the task processing cycle of node 720.

[0176] Figure 7B , the task processing cycle of node 720 is in the first group of 3 beats. Inbound buffer B and outbound buffer B of node 720 are used for communication with node 710 in communication group G0 and communication with node 730 in communication group G1, respectively. Inbound buffer B and outbound buffer B are marked with shaded vertical lines to distinguish them from inbound buffer A and outbound buffer A, and to indicate that they are used for communication process and cannot be used for data processing. Figure 7B In FIG. 1 , the connection lines between the inbound buffer A and the outbound buffer A and the data processing module indicate that the operation of the data processing module in the current data processing cycle uses the inbound buffer A and the outbound buffer A.

[0177] The first three beats of the task processing loop of node 720 are processed in parallel, and the processing of the second three beats of the task processing loop will only proceed after the data receiving beat (communication process of communication group G0) and the data sending beat (communication process of communication group G1) in these three beats are completed.

[0178] Figure 7C A schematic diagram showing the processing status of the second group of 3 beats of the task processing cycle of node 720.

[0179] Figure 7C , the task processing cycle of node 720 is in the second group of 3 beats. Inbound buffer A and outbound buffer A of node 720 are used for communication with node 710 in communication group G0 and communication with node 730 in communication group G1, respectively. Inbound buffer A and outbound buffer A are marked with shaded vertical lines to distinguish them from inbound buffer B and outbound buffer B, and are used to indicate that they are used for communication process and cannot be used for data processing. Figure 7CIn FIG. 1 , the connection lines between the inbound buffer B and the outbound buffer B and the data processing module indicate that the operation of the data processing module in the current data processing beat uses the inbound buffer B and the outbound buffer B.

[0180] The second group of three beats of the task processing loop of node 720 are processed in parallel, and it is necessary to wait for the data receiving beat (communication process of communication group G0) and the data sending beat (communication process of communication group G1) in these three beats to be processed and completed before advancing to the next task processing loop.

[0181] The following pseudo code shows an example of the whole task processing loop of the application of the node 720. The task processing loop includes a first group and a second group each including 3 beats, and the two groups have the same code structure. The node 720 receives data in the communication group G0, and the received data is processed in the task processing loop, and sends data in the communication group G1, and the sent data is the calculation result generated by the data processing in the task processing loop.

[0182] By setting or changing the process() function, the specific content of the data processing performed by the node 720 can be updated. By updating the communication group G0 / G1, the source of the data received by the node 720 can be changed, and / or the destination of the data sent by the node 720 can be changed. This makes it easy to modify or update the application.

[0183]

[0184] Fig. 8A Shown Figure 7A-7C Schematic diagram of the processing process of the software pipeline formed by the three nodes in .

[0185] Fig. 8A In the figure, the horizontal rightward direction represents the direction of the processing beat. Beats are used to distinguish different stages of the task processing process, but each beat does not have to have the same time length.

[0186] The content in the table indicates the task processing cycle processed by the node in the current beat and the beats within the cycle, where a symbol such as LaSb represents the bth beat of the ath cycle.

[0187] For example, Fig. 8A In the row indicated by node 710, L1S1 to L1S6 recorded in the first 6 tables represent 6 beats in the first task processing cycle of node 710, and L2S1 to L2S4 recorded in the subsequent 4 tables represent the first 4 beats of the second task processing cycle of node 710.

[0188] It should be understood that according to the embodiment of the present application, the beats LaS1-LaS3 of the task processing cycle of each node belong to the first group of task processing cycles. Fig. 8A In FIG, the three beats occur successively, but the three beats are processed in parallel by the nodes where they are located. Similarly, the beats LaS4-LaS6 of the task processing cycle of each node belong to the second group of the task processing cycle, but the three beats are also processed in parallel by the nodes.

[0189] Fig. 8A The oblique arrows in indicate that the beats of different nodes occur simultaneously. For example, the beat L1S3 of node 710 occurs simultaneously with the beat L1S1 of node 720, which represents the communication between nodes 710 and 720 in communication group G0, node 710 is the sender, and node 720 is the receiver. Similarly, the beat L1S3 of node 720 occurs simultaneously with the beat L1S1 of node 730, which represents the communication between nodes 720 and 730 in communication group G1, node 720 is the sender, and node 730 is the receiver. The beat L1S5 of node 710 occurs simultaneously with the beat L1S4 of node 720, which represents the communication between nodes 710 and 720 in communication group G0. The beat L1S5 of node 720 occurs simultaneously with the beat L1S4 of node 730, which represents the communication between nodes 720 and 730 in communication group G1.

[0190] Since the beats L1S1-L1S3 of the node 710 occur in parallel, the beats L1S1-L1S3 of the node 720 also occur in parallel, so the data processing beat L1S3 of the node 710 can overlap in time with the data processing beat L1S3 of the node 720. Similarly, the data processing beat L1S3 of the node 720 can overlap in time with the data processing beat L1S3 of the node 730.

[0191] According to the embodiment of the present application, between every two adjacent nodes, the progress of the task processing cycle of the latter node lags behind by two beats compared with the previous node. In the same beat, the three nodes of the system each run different stages of the task processing cycle. Thus, multiple nodes with data dependencies can continuously work together, thereby improving the overall task processing performance.

[0192] Figure 8B Shown Figure 7A-7C Schematic diagram of the processing process of the task processing cycle of the middle node 720.

[0193] In beats t0-t2, node 720 is in the first three beats of the task processing loop, sending data to node 730 through outbound buffer B (expressed as SEND), receiving data from node 710 through inbound buffer B (expressed as RECV), and performing data processing using inbound buffer A and outbound buffer A (expressed as PROC). Since haos_i_send() representing the data sending beat and haos_i_recv() representing the data receiving beat are both non-blocking functions, these two functions return immediately after being called (expressed as the first B mark of the SEND line has a horizontal length of almost 0, and the first B mark of the RECV line has a horizontal length of almost 0), and then node 720 calls process() representing the data processing beat. The process() function is blocking, and its processing takes some time (expressed as the first A mark of the PROC line occupies a certain length in the horizontal direction). After Process() completes and returns, the code while(1!=haos_test(nSendReq)||1!=haos_test(nRecvReq)) is used to wait until both the data sending beat and the data receiving beat are processed (indicated by the first B mark of the TEST line occupying a certain length in the horizontal direction).

[0194] Then node 720 enters the second group of 3 beats of the task processing loop, sends data to node 730 through outbound buffer A (indicated by the first A mark in the SEND line), receives data from node 710 through inbound buffer A (indicated by the first A mark in the RECV line), and uses inbound buffer B and outbound buffer B to process data (indicated by the second B mark in the PROC line). After Process() is completed and returned, wait for both the data sending beat and the data receiving beat to be processed (indicated by the second A mark in the TEST line occupying a certain length in the horizontal direction). Then node 720 enters the first group of 3 beats of the next task processing loop. The task processing process in each task processing loop is the same, so that the loop structure can be used to implement it in the application and the same code can be used in the loop body.

[0195] Figure 8B The processing time of each beat (or code segment) in the task processing loop of the application of node 720 is shown. In the application, the time occupied by data communication (data sending beat and data receiving beat) is very little compared with the data processing beat, and the main processing time is used in the data processing beat. Thus, by using the framework of the application according to the embodiment of the present application, the concurrent processing of data communication and data processing is realized without significantly increasing the code complexity of the task processing loop of the application, and the software pipeline of multiple nodes cooperating to process tasks is realized.

[0196] In addition to Figures 7A-7C The application architecture shown, the message communication middleware according to the embodiment of the present application can also be used in other application frameworks to promote the implementation of a multi-processor distributed parallel computing system based on Feiteng FT-6678N.

[0197] In the application architecture of the node according to another embodiment of the present application, the node can use a single inbound cache and a single outbound cache, the inbound cache is used to receive data sent by the previous node, and the outbound cache is used to send data to the node behind. The previous node, the current node and the next node together constitute a software pipeline to collaboratively process tasks.

[0198] The task processing cycle of the current node includes, for example, 3 beats. In the first beat, data is sent to the next node through the following code,

[0199] nSendReq=haos_i_send(hGroup_1,pOutBuf_A);

[0200] while(1!=haos_test(nSendReq));

[0201] The parameter hGroup_1 represents the communication group to which the current node and the next node belong, the parameter pOutBuf_A represents the outbound buffer, and nSendReq represents the non-blocking communication object handle.

[0202] In the first beat, haos_test(nSendReq) is cyclically executed to detect whether the data communication of the first beat is completed, and after the data communication is completed, the first beat is processed and completed.

[0203] In the second beat, the following code is used to receive data from the previous node.

[0204] nRecvReq=haos_i_recv(hGroup_0,pInBuf_A);

[0205] while(1!=haos_test(nRecvReq));

[0206] The parameter hGroup_0 represents the communication group to which the current node and the previous node belong, the parameter pInBuf_A represents the inbound buffer, and nRecvReq represents the non-blocking communication object handle.

[0207] In the second beat, haos_test(nRecvReq) is cyclically executed to detect whether the data communication of the second beat is completed, and after the data communication is completed, the second beat is processed and completed.

[0208] In the third beat, data processing is performed by calling process(pInBuf_A, pOutBuf_A). The data processing process uses the data in the inbound buffer pInBuf_A obtained from the previous node in the second beat, and the results generated by the data processing process can be placed in the outbound buffer pOutBuf_A and sent to the next node in the subsequent task processing cycle.

[0209] In this embodiment, the first beat, the second beat and the third beat are executed in series, rather than in parallel. Therefore, its data processing performance may be lower than that according to Figure 7A-7C However, since the data received from the previous node appears after the inbound buffer pInBuf_A, the data processing process can start immediately, so the delay of data processing may be low. And in this embodiment, only a single inbound buffer and outbound buffer can be used, so that the data processing task can be completed with relatively fewer buffers.

[0210] In the application architecture of a node according to another embodiment of the present application, the node may use two inbound caches and two outbound caches. Figure 7A-7C Similar to the approach shown in , in a task processing cycle, one pair of inbound buffer and outbound buffer is used for data communication with neighboring nodes, while another pair of inbound buffer and outbound buffer is used for data processing.

[0211] The task processing cycle of the current node includes, for example, 6 beats. In the first beat, the following code is used to send data to the next node,

[0212] nSendReq=haos_i_send(hGroup_1,pOutBuf_B);

[0213] while(1!=haos_test(nSendReq));

[0214] The parameter hGroup_1 represents the communication group to which the current node and the next node belong, the parameter pOutBuf_B represents the outbound buffer, and nSendReq represents the non-blocking communication object handle.

[0215] In the second beat, the following code is used to receive data from the previous node.

[0216] nRecvReq=haos_i_recv(hGroup_0,pInBuf_B);

[0217] while(1!=haos_test(nRecvReq));

[0218] The parameter hGroup_0 represents the communication group to which the current node and the previous node belong, the parameter pInBuf_B represents the inbound buffer, and nRecvReq represents the non-blocking communication object handle.

[0219] In the third beat, data processing is performed by calling process(pInBuf_A, pOutBuf_A), which uses the inbound buffer pInBuf_A and the outbound buffer pOutBuf_A.

[0220] In this embodiment, the first beat, the second beat, and the third beat are executed serially rather than in parallel.

[0221] Next, the two pairs of inbound and outbound buffers are exchanged. In the fourth beat, the following code is used to send data to the next node.

[0222] nSendReq=haos_i_send(hGroup_1,pOutBuf_A,nLen);

[0223] while(1!=haos_test(nSendReq)).

[0224] In the fifth beat, the following code is used to receive data from the previous node.

[0225] nRecvReq=haos_i_recv(hGroup_0,pInBuf_A);

[0226] while(1!=haos_test(nRecvReq));

[0227] In the sixth beat, data processing is performed by calling process(pInBuf_B, pOutBuf_B), which uses the inbound buffer pInBuf_B and the outbound buffer pOutBuf_B.

[0228] In this embodiment, the fourth beat, the fifth beat and the sixth beat are also executed serially instead of being executed in parallel.

[0229] According to another embodiment of the present application, the message communication middleware also supports the application programs of the nodes of the Feiteng FT-6678N multi-processor distributed parallel computing system to perform message communication based on the subscription and publication communication mode by implementing the haos_i_publish() communication interface and the haos_i_subscribe() communication interface.

[0230] According to an embodiment of the present application, the application uses a subscription and publication communication mode including a topic discovery process and a topic message communication process.

[0231] In the topic discovery process, the publisher of the message publishes the topic in the distributed parallel computing system through the haos_i_publish() communication interface. The topic name of the published topic is globally unique (e.g., "Topic_1"), which is used to represent the published topic. The subscriber of the message subscribes to the topic in the distributed parallel computing system through the haos_i_subscribe() communication interface, and uses the globally unique topic name to identify the subscribed topic.

[0232] During the topic discovery process, there is no requirement for the order in which publishers publish topics and subscribers subscribe to topics. There can be no limit on the number of subscribers to a particular topic. Thus, there can be one publisher and any number of subscribers to a particular topic. There can also be no limit on when a subscriber subscribes to a topic. Even if a publisher is already publishing messages on a particular topic, new subscribers can still subscribe to the topic and receive subsequent messages on the topic.

[0233] In a distributed parallel computing system, multiple topics with different topic names can exist simultaneously. These multiple topics can be published by the same publisher or different publishers. These topics can be subscribed by the same or different subscribers.

[0234] Through the subject discovery process, the subscribers and publishers of a specific subject are identified. In the following subject message communication process, the publisher sends a message with a specific subject, and the subscriber will receive the message with the specific subject to which it has subscribed. The publisher sends a message with a specific subject through, for example, haos_i_send() or haos_i_scatter() communication interfaces. The subscriber receives the message of the subscribed subject through, for example, haos_recv() communication interface. Since a specific subject has a single publisher, according to an embodiment of the present application, the subscriber does not use the haos_i_gather() communication interface in a communication mode based on subscription and publication.

[0235] The topic messaging process can be continuous, during which multiple messages with a specific topic can be delivered.

[0236] The haos_i_publish() / haos_i_subscribe() communication interface uses the topic name as a parameter to identify the topic being published or subscribed, without knowing the physical information of the publisher and subscriber. The message communication middleware creates a communication group for each topic, so that the globally unique topic name corresponds to the communication one-to-one, and the communication group can be uniquely identified. As an example, the topic name is used as the name of the communication group. The members of the communication group represented by the topic name are the publisher of the topic that publishes the topic name and the subscribers who subscribe to the topic with the same topic name. The publisher is the sender of the communication group, and the subscriber is the receiver of the communication group. There is a single sender and multiple receivers in the communication group. Therefore, after the communication group is created, the members of the group transmit data by calling haos_i_send() / haos_i_scatter() / haos_i_recv() to realize message communication based on subscription and publication. The haos_i_send() / haos_i_scatter() communication interface is used to realize the publishing of messages to the receivers in the communication group.

[0237] Optionally, the number of members in the communication group is dynamic. The publisher and the subscriber communicate messages based on the current members of the communication group. And the subscriber is allowed to dynamically join or leave the communication group. After the subscriber joins or leaves the communication group, the publisher's newly published message is sent to all current subscribers of the communication group.

[0238] Fig. 9A and Fig. 9B A schematic diagram showing a topic discovery process in a subscription and publication communication mode according to an embodiment of the present application.

[0239] Each node of the multi-processor distributed parallel computing system based on Feiteng FT-6678N runs independently. Therefore, in the process of topic discovery, the order in which the topic publisher calls the haos_i_publish() communication interface and the topic subscriber calls the haos_i_subscribe() communication interface is uncertain.

[0240] exist Fig. 9A In the embodiment of the present invention, the topic publisher first calls the communication interface of haos_i_publish(), and the topic subscriber then calls the communication interface of haos_i_subscribe(). Fig. 9B In the embodiment, the topic publisher calls the haos_i_publish() communication interface later, and the topic subscriber calls the haos_i_subscribe() communication interface first.

[0241] Regardless of whether the haos_i_publish() / haos_i_subscribe() communication interface is called, the publisher and subscriber run a daemon thread to monitor data in the network.

[0242] See also Fig. 9A , two FT-6687N nodes (910 and 920) are coupled via SRIO / EDMA and optional Ethernet. The application of FT-6687 node 910 first calls the communication interface haos_i_publish() to publish the topic; the application of FT-6687 node 920 then calls the communication interface haos_i_subscribe() to subscribe to the topic.

[0243] In response to the application of FT-6687 node 910 calling the communication interface haos_i_publish(), the message communication middleware of node 910 sends a UDP multicast packet ( Fig. 9A The UDP multicast packet carries the published topic name, the IP address of the node (910), the SRID and other information. The message communication middleware of the node 910 also creates a communication group associated with the topic name based on the topic name to be published, and acts as a primary member ( Fig. 9A Node 910 also queries the data cache to identify whether a UDP multicast packet representing the subscribed topic has been received. Fig. 9A In the example, at this time, node 920 has not yet called haos_i_subscribe(), so node 910 has not yet received the UDP multicast packet representing the subscription topic.

[0244] The message communication middleware of node 920 monitors the UDP multicast packet from node 910 from the network ( Fig. 9A Indicated by (2) in the figure), the representative node 910 is identified to have called haos_i_publish() through the content of the UDP multicast packet, and the topic name, publisher (910) IP address, publisher SRID and other information carried by the UDP multicast packet are recorded in the local data cache. At this time, node 920 does not respond to node 910 regarding the UDP multicast packet.

[0245] At some point in the next moment, the application of node 920 calls the communication interface haos_i_subscribe(). In response, the message communication middleware of node 920 obtains the topic name carried by the communication interface haos_i_subscribe() and sends a UDP multicast packet to the network representing the topic that node 920 wants to subscribe to. The UDP multicast packet carries the subscribed topic name, the IP address of the node (920), the SRID and other information ( Fig. 9Aindicated by (3) in the figure).

[0246] Optionally, the message communication middleware of node 910 monitors the UDP multicast packet from node 920 from the network. Since node 910 has called haos_i_publish() to publish the same topic, node 910 responds to node 920. Node 920 can join the communication group associated with the subscribed topic based on the response.

[0247] In response to calling haos_i_subscribe(), the message communication middleware of node 920 also checks from its local cache whether it has received a UDP multicast packet representing that the same topic name has been published. If the local cache identifies that the topic with the same topic name has been published, it adds itself to the communication group associated with the topic name pair, and node 920, as a member of the communication group ( Fig. 9A Indicated by (3-1) in the figure), and respond to the publisher according to the cached physical information of the publisher of the topic name (such as the IP address), for example, by sending a UDP packet to respond to the publisher ( Fig. 9A The UDP packet carries, for example, an indication that node 920 has subscribed to the topic, as well as information such as the IP address and SRID of node 920 as a subscriber. As a subscriber, node 920 also calls the communication interface haos_i_recv() ( Fig. 9A Indicated by (3-3) in the figure), waiting to receive a message from the communication group. The received message is the message published by the publisher (node ​​910) on the topic of the topic name next. The communication interface haos_i_recv() is asynchronous. After it is called, the application of node 920 can continue to process other tasks. After the publisher publishes a message to the topic, the message communication middleware will receive the message and notify the application of node 920 as the subscriber.

[0248] The way in which the message communication middleware of node 920 processes the call to the communication interface haos_i_recv() is described in detail in accordance with Figure 3-4 Embodiments of the present application are provided.

[0249] Node 910 responds to receiving the response ( Fig. 9A (indicated by (4) in the figure), knowing that node 910 has subscribed to the topic it previously published, node 920 is added to the communication group associated with the topic name, for example, as a slave member. Thus, when node 910 subsequently publishes a message under the topic, it sends the message to the communication group to use the message communication middleware to send the message to node 920.

[0250] Optionally, node 910 also ends the call to the communication interface haos_i_publish() ( Fig. 9A Indicated by (4-1) in the figure). It is understandable that this is not necessary. By ending the call to the communication interface haos_i_publish(), node 910, as the publisher of the topic, no longer accepts new subscribers. For example, node 910 expects that the topic has N subscribers, and after receiving UDP packets from N subscribers, it ends the call to the communication interface haos_i_publish(). Still optionally, the number of subscribers to the topic is not limited, and subscribers can subscribe to the topic at any time, and node 910 does not end the call to the communication interface haos_i_publish() while the topic is valid.

[0251] When publishing a message on the topic, the application of node 910 sends data to the communication group associated with the topic by calling the haos_i_send() communication interface. The data sent is the message to be published. The application of node 920 receives the message from the topic by calling the haos_i_recv() communication interface. The message communication middleware receives the message from the topic by calling the haos_i_recv() communication interface. Figure 3-4 The embodiment of the present application provides a method for processing the call to the haos_i_send() / haos_i_recv() communication interface to send a message to the node 920. When calling the haos_i_send() / haos_i_recv() communication interface, the communication group associated with the topic name to be published / subscribed is provided as a parameter without specifying the physical information of the node 910 / 920.

[0252] Optionally, the message communication middleware processes the call to the haos_i_send() / haos_i_recv() communication interface in the same way as Figure 3-4 The embodiments provided are different. For example, node 920 Fig. 9AAfter sending a UDP packet to node 910 to inform itself of the message of its specific topic subscription in step 3-2, haos_i_recv() is called to wait for receiving the message of the topic from the publisher. In response to haos_i_recv() being called, node 920 obtains the data cache for receiving data locally and informs node 910 of the address of the data cache. In order to improve real-time performance, the transmission of this information adopts the DIO method, and then notifies the sender node 910 through the doorbell. In response, after receiving the doorbell notification, the sender node 910 directly writes the message of the topic to be sent into the data cache of node 920 through DMA when there is a message of the topic to be sent, and sends a doorbell to node 920 to notify it that the data has been written into its data cache. In response to receiving the doorbell, node 920 knows that it has received the message of the subscribed topic. Then, the non-blocking communication object handle is updated, and the status of the corresponding communication completion can be queried through, for example, the haos_i_test() communication interface, or the corresponding communication completion can be known based on the return of haos_i_wait(). The message of the topic can be obtained from the local data cache in the code after haos_i_wait().

[0253] Furthermore, in order to ensure that the doorbell can be responded to, a "readback" mechanism is added. The doorbell responder writes a response flag at a specified address after responding to the doorbell operation. The sender reads (reads back) the response flag to ensure that the receiver has successfully responded to the doorbell information. Still further, after the message subscriber responds to the doorbell, it also initiates operations to wait for the next message to be received, such as allocating a cache address, notifying the message publisher of the cache address and sending a doorbell notification, and obtaining a newly received message from the data cache in response to the doorbell from the message publisher.

[0254] Since the haos_i_send() / haos_i_recv() communication interfaces are non-blocking, there is no need to know the time when the publisher publishes the message, nor the time when the subscriber receives the message. The publisher can call the haos_i_send() communication interface to publish the message at any time. After the publisher publishes the message, the haos_i_send() communication interface returns immediately, and the publisher's application can continue to process other tasks. The subscriber does not need to receive the message immediately, but can call the haos_i_recv() communication interface at any time to receive the subscribed message. Optionally, before the subscriber subscribes to a topic, the message published by the publisher to the topic can be delivered to the subscriber after the subscriber subscribes to the topic, or it does not need to be delivered to the subscriber.

[0255] Still optionally, the application of node 920 does not need to explicitly call the haos_i_recv() communication interface to receive messages from the topic. As an alternative, a callback function is specified in the parameters of haos_i_subscribe(). The message communication middleware calls the haos_i_recv() communication interface to receive messages of the specified topic. The callback function is called in the message received from the specified topic and the received message is passed to the callback function.

[0256] Still optionally, the application of node 910 does not need to explicitly call haos_i_send() communication interface to receive the message from the topic. As an alternative, the message to be sent is specified in the parameter of haos_i_publish(), and the message communication middleware calls haos_i_send() communication interface to send the message.

[0257] See also Fig. 9B , two FT-6687N nodes (930 and 940) are coupled via SRIO / EDMA and optionally Ethernet. The application of FT-6687 node 930 then calls the communication interface haos_i_publish() to publish the topic; the application of FT-6687 node 940 first calls the communication interface haos_i_subscribe() to subscribe to the topic.

[0258] In response to the application of node 940 calling the communication interface haos_i_subscribe(), the parameters of the communication interface specify the topic to be subscribed. The message communication middleware of node 940 sends a UDP multicast packet ( Fig. 9B The UDP multicast packet carries the subscribed topic name, the IP address of the node (940), the SRID and other information.

[0259] The message communication middleware of nodes 930 and 940 continuously monitors data from the network.

[0260] In response to receiving a UDP packet ( Fig. 9B (Indicated by (2) in the figure), since the application of node 930 has not yet called haos_i_publish() to publish the topic, the UDP packet is only cached locally.

[0261] At some point later, the application of node 930 calls the communication interface haos_i_publish(), and the published topic is specified in its parameters. In response, the message communication middleware of node 930 sends a UDP multicast packet ( Fig. 9B(Indicated by (3) in the figure), the UDP multicast packet carries the published topic name, the IP address of the node (930), the SRID and other information. The message communication middleware of node 930 also creates a communication group associated with the topic name based on the topic name to be published, and serves itself as, for example, a primary member of the communication group. Optionally, the message communication middleware of node 940 monitors the UDP multicast packet from node 930 from the network. Since node 940 has called haos_i_subscribe() to subscribe to the same topic at this time, node 940 gives a response to node 930. Node 930 can add subscriber node 940 to the communication group associated with the subscribed topic based on the response.

[0262] The message communication middleware of node 930 also checks from its local cache whether it has received a UDP multicast packet indicating that the same topic name has been subscribed. If the local cache identifies that the topic with the same topic name has been subscribed, the node (940) subscribed to the topic is added to the communication group as a slave member ( Fig. 9B Indicated by (3-1) in the figure). And send a response to the node (940) that has subscribed to the topic ( Fig. 9B Indicated by (3-2) in the example). Optionally, if multiple subscribers of the topic have been recorded in the local cache, node 930, as a publisher, sends a response to each subscriber. For example, a UDP unicast packet is used to respond to the subscriber. Optionally, node 930 also ends the call to the communication interface haos_i_publish() ( Fig. 9B indicated by (5) in the figure).

[0263] Node 940 monitors the UDP packet from node 930. In response to receiving the response ( Fig. 9B ), knowing that its subscription has been successful, node 940 joins the communication group associated with the subscribed topic and becomes a slave member of the communication group ( Fig. 9B Indicated by (4-1)).

[0264] As a subscriber, node 940 also calls the communication interface haos_i_recv() ( Fig. 9B (indicated by (4-2)), waiting to receive a message from the communication group.

[0265] When a message is to be published on the topic, the application of node 930 sends data to the communication group associated with the topic by calling the haos_i_send() communication interface. The data sent is the message to be published.

[0266] Fig. 10A and Fig. 10B A schematic diagram showing a topic discovery process in a subscription and publication communication mode according to yet another embodiment of the present application.

[0267] See also Fig. 10A , two FT-6687N nodes (1010 and 1020) are coupled via SRIO / EDMA and optionally Ethernet. The application of FT-6687 node 1010 first calls the communication interface haos_i_publish() to publish a topic; the application of FT-6687 node 1020 then calls the communication interface haos_i_subscribe() to subscribe to a topic. Nodes 1010 and 1020 each include a main thread and a daemon thread to process the communication interface call. The code of the main thread and the daemon thread is provided by the message communication middleware. The daemon threads of nodes 1010 and 1020 continuously listen to data from the network.

[0268] In response to the application of node 1010 calling haos_i_publish() ( Fig. 10A Indicated by (1) in the communication interface, the topic to be published is specified in the communication interface parameters. The main thread sends a UDP multicast packet ( Fig. 10A The UDP multicast packet carries the published topic name, the IP address of the node (1010), the SRID and other information. The main thread also creates a communication group ( Fig. 10A Node 1010 also queries the data cache to identify whether it has received a UDP multicast packet representing the subscribed topic. Fig. 10A In the example, at this time, node 1020 has not called haos_i_subscribe(), so node 1010 has not received the UDP multicast packet representing the subscribed topic, and does not need to respond to the UDP multicast packet.

[0269] The daemon thread of node 1020 receives the UDP multicast packet from node 1010 ( Fig. 10A Indicated by (2) in the example), record it in the local cache ( Fig. 10A Indicated by (2-1) in FIG. 10). Through the locally cached records, the daemon thread of node 1020 knows that it has not yet called haos_i_subscribe(), and therefore does not respond to node 1010 regarding the UDP multicast packet.

[0270] At some point later, the application of node 1020 calls haos_i_subscribe(). In response, the main thread of node 1020 sends a UDP multicast packet ( Fig. 10A The UDP multicast packet carries the published topic name, the IP address of the node (1020), the SRID and other information.

[0271] Optionally, the daemon thread of node 1010 monitors the UDP multicast packet from node 1020 from the network. Since node 1010 has called haos_i_publish() to publish the same topic, the daemon thread of node 1010 responds to node 1020. The daemon thread of node 1020 receives the response and can join the communication group associated with the subscribed topic as a slave member based on the response.

[0272] In response to haos_i_subscribe() being called, the main thread of node 1020 also queries the local cache for a UDP multicast packet carrying the same topic name as that specified in the parameters of haos_i_subscribe(). Fig. 10A In the embodiment, since such UDP packets exist in the local cache of node 1020, node 1020 knows that the topic corresponding to the topic name has been published. Accordingly, node 1020 can join the communication group associated with the topic name, and itself serves as a slave member ( Fig. 10A Indicated by (3-1) in the figure). The main thread of node 1020 also responds to the publisher corresponding to the topic name to inform it that it has subscribed to the topic ( Fig. 10A Indicated by (3-2) in the figure). Optionally, node 1020 also calls haos_i_recv() in the main thread to wait for receiving the message of the topic ( Fig. 10A Indicated by (3-3)).

[0273] In response to receiving the response from node 1020, the daemon thread of node 1010 adds node 1020 to the communication group associated with the subscribed topic name and makes it a slave member ( Fig. 10A Optionally, the daemon thread of node 1010 also notifies the main thread to end the call to the communication interface haos_i_publish() ( Fig. 10A Indicated by (4-1)).

[0274] See also Fig. 10B , two FT-6687N nodes (1030 and 1040) are coupled via SRIO / EDMA and optional Ethernet. The application of FT-6687 node 1030 then calls the communication interface haos_i_publish() to publish a topic; the application of FT-6687 node 1040 first calls the communication interface haos_i_subscribe() to subscribe to a topic. Nodes 1030 and 1030 each include a main thread and a daemon thread to process the communication interface call. The code of the main thread and the daemon thread is provided by the message communication middleware. The daemon threads of nodes 1030 and 1040 continuously listen to data from the network.

[0275] In response to the application of node 1040 calling the communication interface haos_i_subscribe(), the parameters of the communication interface specify the topic to be subscribed. The main thread of node 1040 sends a UDP multicast packet ( Fig. 10B The UDP multicast packet carries the subscribed topic name, the IP address of the node (1020), the SRID and other information.

[0276] The daemon thread of node 1030 monitors the network and responds to receiving a UDP packet ( Fig. 10B Indicated by (2) in the figure), since the application of node 1030 has not yet called haos_i_publish() to publish the topic, the UDP packet is only cached locally without responding to the UDP multicast packet.

[0277] At some point later, the application of node 1030 calls the communication interface haos_i_publish(), and its parameters specify the topic to be published. The main thread of node 1030 sends a UDP multicast packet ( Fig. 10B (indicated by (3) in the figure) to inform the network that it has published the topic. The UDP multicast packet carries the published topic name, the IP address of this node (1030), the SRID and other information. A communication group associated with the topic name is created, and the node itself is the main member of the communication group. Optionally, the slave thread of node 1040 monitors the UDP multicast packet from node 1030 from the network. Since node 1040 has called haos_i_subscribe() to subscribe to the same topic at this time, node 1040 gives a response to node 1030. Node 1030 can add subscriber node 1040 to the communication group associated with the subscribed topic based on the response.

[0278] The main thread of node 1030 also checks from its local cache whether it has received a UDP multicast packet indicating that the same topic name has been subscribed. Since it is identified from the local cache that the topic with the same topic name has been subscribed, the main thread adds the node (1040) that has subscribed to the topic with the topic name as a slave member to the communication group. The main thread of node 1030 responds to the subscriber according to the cached physical information (such as IP address) of the subscriber with the topic name ( Fig. 10B (indicated by (3-2) in the figure), the response is, for example, a UDP unicast packet. Optionally, if multiple subscribers of the topic have been recorded in the local cache, node 1030, as a publisher, sends the UDP unicast packet to each node, or responds to each subscriber via a UDP multicast packet. Optionally, the main thread of node 1030 also ends the call to the communication interface haos_i_publish() ( Fig. 10B indicated by (5) in the figure).

[0279] The daemon thread of node 1040 listens to the UDP packet from the network, and responds to the response ( Fig. 10B Indicated by (4) in the figure), it recognizes that its subscription is successful, and then node 1040 joins the communication group associated with the topic name, and itself becomes a slave member of the communication group ( Fig. 10B Indicated by (4-1)).

[0280] As a subscriber, the daemon thread of node 1040 also calls the communication interface haos_i_recv() ( Fig. 10B (indicated by (4-2)), waiting to receive a message from the communication group.

[0281] Figures 9A-10B The embodiment of the present invention shows the subject discovery process of the subscription and publication communication mode according to the embodiment of the present invention. In the message communication process of the subscription and publication communication mode, the publisher of the subject message sends the message of a specific subject to the communication group associated with the subject by calling the haos_i_send() or haos_i_scatter() communication interface. The subscriber of the subject message receives the message from the communication group associated with the specific subject by calling haos_i_recv(). The implementation of the haos_i_send(), haos_i_scatter() and haos_i_recv() communication interfaces can be referred to. Figure 3-Figure 4 The embodiment shown.

[0282] Optionally, the message communication middleware processes the call to the haos_i_send() / haos_i_recv() communication interface in the same way as Figure 3-4 The examples provided are different. Fig.11 The message communication process of the subscription and publication communication mode according to another embodiment of the present application is demonstrated.

[0283] Fig.11 In the example, two FT-6687N nodes (1110 and 1120) are coupled via SRIO / EDMA and optionally Ethernet. FT-6687 node 1110 calls haos_i_send to publish a message; the application of FT-6687 node 1120 calls the communication interface haos_i_recv() to receive messages of the subscribed topic. As an example, the call to haos_i_recv() by FT-6687 node 1120 occurs first.

[0284] Node 1120 calls haos_i_recv() to wait for receiving messages from the publisher on this topic ( Fig.11In the example, haos_i_recv() indicates a receive data cache, and a communication group associated with the subject of the message to be received. In response to haos_i_recv() being called, node 1120 obtains a data cache for receiving data locally, notifies node 1110 of the address of the data cache ( Fig.11 Indicated by (1-1) in the figure). In order to improve real-time performance, the information is sent in the DIO mode, and then the node 1110 is notified through the doorbell. The communication interface haos_i_recv() is non-blocking, so it returns immediately after being called, so that the node 1110 continues to execute the subsequent code. Optionally, the subsequent codes of the node 1110 include a call to the communication interface haos_i_wait() to wait for the data receiving process corresponding to haos_i_recv() to be completed.

[0285] In response, after receiving the doorbell notification, node 1110 identifies whether there is a message of the subject to be sent. This depends on whether node 1110 has called haos_i_send() to send data to the communication group associated with the subject when receiving the doorbell. Fig.11 In FIG. 1 , the call of haos_i_send() by node 1110 is indicated by (2). The communication interface haos_i_send() is non-blocking, so it returns immediately after being called, so that node 1110 continues to process other operations.

[0286] When there is a message of the subject to be sent, node 1110 directly writes the message of the subject to be sent into the data cache of node 1120 through DMA, and sends a doorbell to node 1120 to notify it that the data has been written into its data cache ( Fig.11 indicated by (4) in the figure).

[0287] If node 1110 has not called haos_i_send() to send data to the communication group associated with the topic when receiving the doorbell notification, the address of the received data cache indicated by the doorbell notification is cached.

[0288] Node 1120 responds to the doorbell sent by node 1110 at (4), and node 1120 knows that it has received the message of the subscription topic ( Fig.11 Indicated by (5) in the figure). Then, the non-blocking communication object handle representing the communication process of calling haos_i_recv() is updated, and the status of the corresponding communication completion can be queried through, for example, the haos_i_test() communication interface, or the corresponding communication completion can be known based on the return of haos_i_wait(). The message of the topic can be obtained from the local data cache in the code after haos_i_wait().

[0289] Furthermore, after the message subscriber obtains the subscribed message, it also initiates an operation of waiting for receiving the next message, such as calling another haos_i_recv() to wait for receiving the next published message ( Fig.11 indicated by (5) in the figure).

[0290] Still further, in order to enable the sender of the doorbell to recognize that the doorbell has been responded to, a "readback" mechanism is added. The doorbell responder writes a response flag at a specified address after responding to the doorbell operation. The sender reads (reads back) the response flag to ensure that the receiver has successfully responded to the doorbell information. See also Fig.11 After node 120 obtains the subscribed message, it also writes a response flag to the designated address corresponding to the doorbell. Node 1110 recognizes that the message subscriber has successfully received the message through the appearance of the response flag, thereby ending the haos_i_send() communication process corresponding to the message. Fig.11 indicated by (6)).

[0291] The process of the message publisher publishing the message through haos_i_scatter() is the same as Fig.11 The display process is similar and will not be described here.

[0292] According to one embodiment of the present application, in order to perform message communication using the subscription and publication communication mode provided in the embodiment of the present application, the message publisher calls haos_i_publish() to publish a topic, and specifies the topic name of the published topic in the parameters, while the message receiver calls haos_i_subscribe() to subscribe to a topic, and specifies the topic name of the subscribed topic in the parameters. The message communication middleware of the publisher and the receiver jointly processes the calls to haos_i_publish() and haos_i_subscribe(), establishes a communication group associated with the topic name, and the publisher and the receiver are both members of the communication group. Optionally, the publisher serves as the primary member of the communication group, and the receiver serves as the secondary member of the communication group.

[0293] Publishers and subscribers communicate through communication groups to publish and receive messages on specified topics. When publishing a message on a certain topic, the publisher calls haos_i_send() / haos_i_scatter() and specifies the communication group and the message to be published in the parameters. Therefore, the publisher only needs to send the message to the communication group to complete the message publishing without having to care about the physical information of each subscriber. The communication group is associated with the topic to which the message to be published belongs. The receiver only needs to call haos_i_recv() / receive messages from the communication group to receive messages on the subscribed topic. The sender and the receiver do not need to care about the behavior of the message communication counterpart, for example, whether the message has been published, whether it can be received, or whether it has been received. This greatly simplifies the complexity of the message communication process required by the application.

[0294] After completing the subscription to the message, the subscriber can continue to receive messages from the same topic without repeating the subscription process. The publisher can also continue to publish messages on the same topic.

[0295] Since the subscription and publication of messages correspond to the communication groups one by one, multiple topics can be published / subscribed at the same time, and communication can be carried out based on multiple topics respectively. The message communication of each topic is also concurrent. The same publisher can publish multiple topics at the same time, and the same receiver can subscribe to multiple topics at the same time. The message communication middleware establishes a communication group uniquely associated with each topic, and processes the message communication of the topic associated with it based on the communication group. The processing of the message communication of each communication group is processed according to the method provided in the embodiment of the present application, and the processing method of the message communication of each communication group can be the same. In addition, the node running the publisher application can also act as a subscriber at the same time. Vice versa.

[0296] Various ways of utilizing the message communication middleware according to the embodiments of the present application have been provided, and those skilled in the art will understand the various ways of using the message communication middleware according to the embodiments of the present application in an application to perform data communication and collaborative data processing between nodes.

[0297] The multi-processor distributed parallel computing system node based on Feiteng FT-6678N running the message communication middleware / application of the embodiment of the present application includes, for example, a memory, one or more processors, one or more presentation components, I / O components, and a power supply directly or indirectly coupled to a bus. The bus may represent one or more buses (such as an address bus, a data bus, or a combination thereof).

[0298] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application. Obviously, those skilled in the art may make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for implementing a message communication middleware in a subscription and publishing communication mode, wherein the message communication middleware runs on each node of a Feiteng FT-6678N multi-processor distributed parallel computing system including multiple nodes, and each node is coupled via an SR IO link, and the method comprises: In response to the communication interface haos_i_publish() being called, the method obtains a parameter representing a topic to be published from the communication interface, sends a first data packet representing the publisher carrying the topic to be published and its own network address to each node of the parallel computing system, creates a communication group associated with the topic to be published, and uses itself as a primary member of the created communication group; In response to receiving a second data packet on behalf of a subscriber carrying a topic to be subscribed and a network address of the subscriber, if the topic to be subscribed is consistent with the topic to be published, treating the subscriber as a slave member of the created communication group; In response to the communication interface haos_i_subscribe() being called, obtaining parameters representing the topic to be subscribed from the communication interface, sending a second data packet representing the subscriber carrying the topic to be subscribed and its own network address to each node of the parallel computing system, and acting as a slave member of the communication group associated with the topic to be subscribed; In response to receiving a first data packet on behalf of a publisher carrying a topic to be published and a publisher network address, if the topic to be published is consistent with the topic to be subscribed, the publisher is made a primary member of a communication group associated with the topic to be subscribed.

2. The method according to claim 1, wherein: In response to receiving a second data packet on behalf of a subscriber carrying a topic to be subscribed and a network address of the subscriber, if the topic to be subscribed is consistent with the topic to be published, further sending a response data packet to the subscriber; In response to receiving a response data packet sent by the subscriber to the first data packet, the subscriber is regarded as a slave member of the created communication group; In response to receiving a first data packet on behalf of a publisher carrying a topic to be published and a network address of the publisher, if the topic to be published is consistent with the topic to be subscribed, further sending a response data packet to the publisher; In response to receiving a response data packet sent by the publisher to the second data packet, the publisher is taken as a primary member of the created communication group.

3. The method according to claim 2, wherein: The first data packet and the second data packet are UDP multicast packets; The response data packet is a UDP unicast packet or a UDP multicast packet.

4. The method according to claim 3, wherein: In response to receiving a second data packet on behalf of a subscriber carrying a topic to be subscribed and a network address of the subscriber, if the topic to be subscribed has not been published, caching the second data packet and not sending a response data packet to the subscriber; In response to receiving a first data packet on behalf of a publisher carrying a topic to be published and a publisher network address, if the topic to be published has not been subscribed, the first data packet is cached and no response data packet is sent to the publisher.

5. The method according to any one of claims 1 to 4, wherein: In response to the communication interface haos_i_send() being called, obtaining parameters representing the communication group and parameters representing the data to be sent from the communication interface, and returning the call to the communication interface haos_i_send(); In response to the communication interface haos_i_recv() being called, obtaining parameters representing the communication group and parameters representing the data cache for receiving data from the communication interface, informing the sender of the communication group of the cache address for receiving data, and returning the call to the communication interface haos_i_recv(); In response to receiving a buffer address for receiving data from a receiving party of the communication group, the data to be sent is moved to the buffer for receiving data, and the communication process corresponding to the communication interface haos_i_send() is marked as completed; In response to receiving the data to be sent from the sender of the communication group, it is marked that the communication process corresponding to the communication interface haos_i_recv() has been processed.

6. The method according to claim 5, wherein: In response to the communication interface haos_i_recv() being called, the buffer address for receiving data is sent to the sender of the communication group through the DIO mode, and the sender of the communication group is also informed through the doorbell that the buffer address for receiving data has been sent to it; In response to receiving the doorbell, the sender of the communication group recognizes that a cache address for receiving data is received from the receiver of the communication group; In response to receiving a buffer address for receiving data from a receiving party of the communication group, after moving the data to be sent to the buffer for receiving data, the receiving party of the communication group is notified through a doorbell that the data to be sent has been moved to the buffer for receiving data; In response to receiving the doorbell, the receiving party of the communication group recognizes that the data to be transmitted already exists in the buffer for receiving data.

7. The method according to claim 6, wherein: The sender of the communication group responds to receiving the doorbell by also writing a response mark at the designated address, and the receiver of the communication group recognizes that the sender of the communication group has successfully responded to the doorbell by reading the response mark; and / or In response to receiving the doorbell, the receiver of the communication group also writes a response tag at the specified address, and the sender of the communication group recognizes that the receiver of the communication group has successfully responded to the doorbell by reading the response tag.

8. The method according to any one of claims 1 to 4, wherein: In response to the communication interface haos_i_send() being called, obtaining parameters representing the communication group and parameters representing the data to be sent from the communication interface, and returning the call to the communication interface haos_i_send(); The master member of the communication group that calls the communication interface haos_i_send() informs the slave members of the communication group that it has called the communication interface haos_i_send(), and informs the data cache address of the data to be sent; In response to the communication interface haos_i_recv() being called, obtaining parameters representing the communication group and parameters representing the data buffer for receiving data from the communication interface, and returning the call to the communication interface haos_i_recv(); The slave member of the communication group that calls the communication interface haos_i_recv() determines whether the master member of the communication group has called the communication interface haos_i_send(); If the master member of the communication group has called the communication interface haos_i_send(), the data to be sent is moved from the data cache of the master member of the communication group to the data cache for receiving data; In response to receiving the data to be sent from the master member of the communication group, marking the communication process corresponding to the communication interface haos_i_recv() as completed, and notifying the master member of the communication group that it has received the data to be sent; In response to the slave member of the communication group having received the data to be sent, the master member of the communication group that has called the communication interface haos_i_send() marks that the communication process corresponding to the communication interface haos_i_send() has been completed.

9. The method according to claim 8, wherein: The slave member of the communication group that calls the communication interface haos_i_recv() marks that it is ready to receive data if it determines that the master member of the communication group has not called the communication interface haos_i_send(); In response to the master member of the communication group notifying the slave member of the communication group that it has called the communication interface haos_i_send(), the communication group that calls the communication interface haos_i_recv() moves the data to be sent from the data cache of the master member of the communication group to the data cache for receiving data.

10. A method for performing message communication between nodes of a Feiteng FT-6678N multi-processor distributed parallel computing system using a subscription and publishing communication mode, wherein the Feiteng FT-6678N multi-processor distributed parallel computing system comprises a plurality of nodes interconnected by SRIO, each of the nodes runs a message communication middleware, and the plurality of interconnected nodes comprises a first node and a second node; the message communication middleware is used to execute the method according to any one of claims 1 to 9; The method for performing message communication using the subscription and publication communication mode includes: The first node calls the communication interface haos_i_publish() to publish a specified topic, wherein the communication interface haos_i_publish() carries parameters representing the topic; The second node calls the communication interface haos_i_subscribe() to subscribe to the specified topic, where the communication interface haos_i_subscribe() carries parameters representing the topic; The first node treats the message to be sent to the second node as a message published on the specified topic; The second node receives, from the designated topic, a message that the first node is to send to the second node.

11. The method according to claim 10, wherein: The first node calls the communication interface haos_i_send() to publish a message on a specified topic through a subscription and publication communication mode, wherein the communication interface haos_i_send() carries a parameter representing the specified topic and a parameter representing the message to be published, and the parameter representing the specified topic is associated with a communication group used for the communication interface haos_i_send(); The second node calls the communication interface haos_i_recv() to receive a message from the specified topic, wherein the communication interface haos_i_recv() carries parameters representing the specified topic and parameters representing the cache of the message to be received, and the parameters representing the specified topic are associated with the communication group used for the communication interface haos_i_recv().

12. The method according to claim 11, further comprising: One or more third nodes call the communication interface haos_i_subscribe() to subscribe to the specified topic, wherein the communication interface haos_i_subscribe() carries parameters representing the topic; The first node sends a message to the second node and one or more third nodes as a message published on a specified topic through a subscription and publication communication mode; The one or more third nodes receive the message that the first node is to send to the second node and the one or more third nodes from the designated topic through a subscription and publishing communication mode; Each third node calls the communication interface haos_i_recv() to receive messages from the specified topic.

13. The method according to claim 11, wherein: The first node repeatedly calls the communication interface haos_i_send() to publish multiple messages on the specified topic through the subscription and publication communication mode; The second node repeatedly calls the communication interface haos_i_recv() to receive multiple messages from the specified topic.

14. A computing device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 13 when executing the program.

Images