Data transceiving method and apparatus based on multi-thread, medium and device

Abstract

Disclosed are a multi-thread-based data transceiving method and device, a medium and equipment. The method comprises the following steps: assigning multiple tasks to multiple processes based on an OpenMPI open message transmission interface; assigning tags to the multiple tasks respectively; sending corresponding relationship information of the tasks, the processes and the tags to a task receiver; based on an OpenMP open multi-processing multi-thread mode, sending content size of the multiple tasks to each task receiver respectively according to the corresponding relationship information of the tasks and the tags, so that a corresponding process in each task receiver sets a cache area according to the received content size; based on the OpenMP multi-thread mode, sending content of the multiple tasks to each task receiver respectively according to the corresponding relationship information of the tasks and the tags, so that a corresponding process in each task receiver receives the tasks according to the tags and stores them in the corresponding cache area. The present disclosure is beneficial to improving the security of multi-thread-based data transceiving.

Description

Technical Field

[0001] This disclosure relates to data transmission technology, and in particular to a multi-threaded data transmission and reception method, a multi-threaded data transmission and reception device, a storage medium, and an electronic device. Background Technology

[0002] OpenMPI (OpenMessage Passing Interface) enables parallel computing by distributing tasks to multiple processes.

[0003] OpenMPI can be used in multi-threaded environments. However, in multi-threaded environments, due to the acceleration of threads, the order in which the same compute node receives data is often uncertain. Therefore, when processing this data, the compute node may encounter the problem of disordered data order, which will cause the data receiving order to be inconsistent with the expected processing order. The compute node cannot accurately process the received data, which may cause the received data to be unable to be accurately written to the corresponding buffer area, thus causing a buffer overflow error.

[0004] Ensuring the security of data transmission and reception in a multi-threaded environment is a technical issue that deserves attention. Summary of the Invention

[0005] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a multi-threaded data transmission and reception method, apparatus, storage medium, and electronic device.

[0006] According to a first aspect of the present disclosure, a multi-threaded data transmission and reception method is provided, comprising: assigning multiple tasks to multiple processes based on an OpenMPI open message transmission interface; assigning tags to the multiple tasks respectively, wherein different tasks have different tags; sending correspondence information of the tasks, processes and tags to task receivers, so that processes in each task receiver wait to receive the corresponding task according to the tag; according to the correspondence information of the tasks and tags, and based on the OpenMP open multi-processing multi-threading method, sending the content size of the multiple tasks to each task receiver respectively, so that the corresponding processes in each task receiver set up a buffer according to the received content size; according to the correspondence information of the tasks and tags, and based on the OpenMP multi-threading method, sending the content of the multiple tasks to each task receiver respectively, so that the corresponding processes in each task receiver receive the task according to the tag and store it in the corresponding buffer.

[0007] According to a second aspect of the present disclosure, another multi-threaded data transmission and reception method is provided, comprising: receiving correspondence information of tasks, processes, and tags from a task sender; setting a corresponding OpenMPI-based process in a waiting-to-receive state on a corresponding tag according to the correspondence information; when the process receives the content size of a task from the task sender based on the tag in the correspondence information and using an OpenMP multi-threaded approach, setting a buffer based on the content size of the task; when the process receives the content of a task from the task sender based on the tag in the correspondence information and using an OpenMP multi-threaded approach, storing the content of the task in the buffer; the process executing the task according to the content of the task stored in the buffer, and returning the execution result of the task to the task sender according to the tag in the correspondence information.

[0008] According to a third aspect of the present disclosure, a multi-threaded data transceiver device is provided, comprising: a task allocation module for allocating multiple tasks to multiple processes based on OpenMPI; a tag allocation module for assigning tags to the multiple tasks respectively, wherein different tasks have different tags; a first tag handshake module for sending correspondence information between the tasks, processes, and tags to task receivers, so that processes in each task receiver wait to receive the corresponding task according to the tag; a first sending module for sending the content size of the multiple tasks to each task receiver respectively based on the correspondence information between the tasks and tags and using an OpenMP multi-threaded approach, so that the corresponding processes in each task receiver set up a buffer according to the received content size; and a second sending module for sending the content of the multiple tasks to each task receiver respectively based on the correspondence information between the tasks and tags and using an OpenMP multi-threaded approach, so that the corresponding processes in each task receiver receive the task according to the tag and store it in the corresponding buffer.

[0009] According to a fourth aspect of the present disclosure, a multi-threaded data transceiver device is provided, comprising: a second tag handshake module, configured to receive correspondence information of a task, process, and tag from a task sender; a waiting-to-receive module, configured to, based on the correspondence information, cause a corresponding OpenMPI-based process to be in a waiting-to-receive state on a corresponding tag; a buffer setting module, configured to, when the process receives the content size of a task from the task sender based on the tag in the correspondence information and in an OpenMP multi-threaded manner, cause the process to set a buffer according to the content size of the task; a task storage module, configured to, when the process receives the content of a task from the task sender based on the tag in the correspondence information and in an OpenMP multi-threaded manner, cause the process to store the content of the task in the buffer; and a task execution module, configured to, cause the process to execute the task according to the content of the task stored in the buffer, and cause the process to return the execution result of the task to the task sender based on the tag in the correspondence information.

[0010] According to a fifth aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for implementing any of the methods described above.

[0011] According to a sixth aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; the processor being configured to read the executable instructions from the memory and execute the instructions to implement any of the methods described above.

[0012] Based on the above embodiments of this disclosure, a multi-threaded data transmission and reception method, apparatus, storage medium, and electronic device are provided. By assigning tags and processes to all tasks and sending the correspondence information of tasks, processes, and tags to each task receiver, the task sender and task receiver can achieve tag handshake for data transmission and reception. Thus, both the task sender and each task receiver can utilize tags and adopt OpenMP multi-threading to realize the content size and transmission and reception of task content. Since the process assigned to the task in the task receiver can use OpenMP multi-threading to quickly and accurately set a buffer of the same size as the task content received from the task sender, the process in the task receiver can use OpenMP multi-threading to quickly and accurately store the content of the task received from the task sender based on the tag in the designated buffer. This ensures data transmission and reception efficiency while effectively avoiding buffer overflow. Therefore, the technical solution provided by this disclosure is beneficial for enriching multi-threaded data transmission and reception technology and improving the data transmission and reception security of the system.

[0013] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0014] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0015] Figure 1 This is a schematic diagram illustrating an application scenario of the multithreaded data transmission and reception method disclosed herein.

[0016] Figure 2 This is a flowchart of an embodiment of the multithreaded data transmission and reception method disclosed herein;

[0017] Figure 3 This is a flowchart illustrating an embodiment of assigning multiple tasks to multiple processes according to the present disclosure;

[0018] Figure 4 This is a flowchart illustrating an embodiment of sending corresponding relationship information to a task recipient according to the present disclosure;

[0019] Figure 5 This is a flowchart of another embodiment of the multithreaded data transmission and reception method disclosed herein;

[0020] Figure 6 This is a flowchart of a specific implementation of the multithreaded data sending and receiving method disclosed herein;

[0021] Figure 7 This is a schematic diagram of the structure of an embodiment of the multi-threaded data transceiver device disclosed herein;

[0022] Figure 8 This is a schematic diagram of another embodiment of the multithreaded data transceiver device disclosed herein;

[0023] Figure 9 This is a structural diagram of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

[0024] Example embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. It is obvious that the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure, and it should be understood that this disclosure is not limited to the example embodiments described herein.

[0025] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0026] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0027] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0028] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0029] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0030] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0031] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0032] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0033] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0034] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0035] The embodiments of this disclosure can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, or servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems, etc.

[0036] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in a distributed cloud computing environment. In a distributed cloud computing environment, tasks can be executed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0037] This disclosure outlines

[0038] In developing this disclosure, the inventors discovered that to avoid buffer overflow issues caused by discrepancies between the order in which the receiver receives data and the expected order in a multi-threaded environment, current solutions are mostly based on strategies to ensure that the data reception order matches the expected order, thereby guaranteeing that the data is stored in the corresponding location in the buffer and preventing buffer overflow. Such solutions can be considered solutions addressing the root cause of the problem. However, some solutions can impact the system's data transmission and reception performance (e.g., affecting data transmission and reception efficiency). Furthermore, the factors causing the receiver to receive data in a different order than expected may not be singular. Shielding all possible factors to prevent buffer overflow without affecting data transmission and reception performance presents a significant challenge. If the phenomenon of potentially inconsistent data reception order exists, addressing buffer overflow from other perspectives not only enriches multi-threaded data transmission and reception technologies but also helps to prevent buffer overflow caused by the inability to shield all possible factors (such as future unknown factors) while ensuring data transmission and reception performance. In other words, regardless of whether the order in which the receiver receives the data matches the expected order, ensuring that the receiver can store the received data in the correct location in the buffer based on a correct understanding can also solve the buffer overflow problem.

[0039] Exemplary Overview

[0040] The multi-threaded data transmission and reception technology disclosed herein is applicable to various application scenarios. For example, the technology provided herein can be applied to file reading and writing, background task execution, cloud computing, and client-server models. A specific example of implementing the technology in any application scenario is as follows: Figure 1 As shown.

[0041] Figure 1 In this configuration, a master node 100 (the task sender) is connected to multiple computing nodes (the task receivers), such as computing nodes 101-1, 101-2, ..., and 101-n (where n is an integer greater than 2). Any two computing nodes can reside on different hardware devices or on the same hardware device. The master node 100 can be located on two different hardware devices with any of the computing nodes, or it can be located on the same hardware device with some of the computing nodes.

[0042] OpenMPI is installed on the master node 100 and each compute node. The master node 100, compute node 101-1, compute node 101-2, ... and compute node 101-n form an OpenMPI cluster.

[0043] Master node 100 has multiple tasks that need to be executed. Master node 100 uses a predetermined allocation strategy to distribute all currently executing tasks to multiple processes in the OpenMPI cluster. The processes in the OpenMPI cluster include those on all compute nodes. Master node 100 assigns a corresponding label and process to each task and performs a label handshake with each compute node executing the task. After the label handshake, the corresponding process on the compute node is in a label-based waiting state. Before distributing the content of each task, master node 100 can first distribute the content size of each task to the corresponding compute node based on its respective label. After receiving the content size of the corresponding task based on its held label, the corresponding process on the compute node sets up a corresponding buffer and stores the task content in that buffer after receiving it based on its held label. After executing their respective tasks, the corresponding processes on each compute node return the execution results to master node 100. Master node 100, based on the labels corresponding to each task, waits to receive the execution results returned by each compute node and continues to execute subsequent operations based on the received results.

[0044] Exemplary methods

[0045] Figure 2 This is a flowchart of an embodiment of the multi-threaded data transmission and reception method disclosed herein. Figure 2 The method shown is executed on the task sender (also known as the task distributor), which is typically an OpenMPI-based master node. This method mainly includes: S200, S201, S202, S203, and S204. The following sections will discuss... Figure 2 Each step in the process will be explained separately.

[0046] S200 assigns multiple tasks to multiple OpenMPI-based processes.

[0047] In this disclosure, a task refers to a basic unit of work that requires computational resources to complete in a multi-process environment. For example, a task may include one or more sequences of instructions. All tasks in this disclosure typically have their own index values; for example, all tasks are numbered sequentially, and the sequential number of the task can be used as the task's index value. The task's index value can also be called the task's identifier. The task's index value is unique, meaning that any two tasks in S200 have different index values.

[0048] The index values ​​of all tasks in this disclosure can be represented by task subscripts or suffixes. For example, assuming the number of tasks in S200 is N (N is an integer greater than 1), and the index values ​​of these N tasks are 0 to N-1, then these N tasks can be represented as task0, task1, ... and task... N-1 It can also be represented as task0, task1, ... and taskN-1.

[0049] This disclosure allows each task to be organized into a one-dimensional array, the contents of which can be all the information contained in the task (such as all instructions). The one-dimensional arrays of all tasks can form a two-dimensional array, which can be named totalTask ​​in the following description.

[0050] In this disclosure, OpenMPI refers to a technology that enables parallel computing in a distributed memory system and allows processes on different computing nodes to communicate and coordinate through message passing. The OpenMPI-based process in this disclosure refers to a process in an OpenMPI cluster, which can be considered as a process pool formed by the resources of multiple OpenMPI nodes (such as all nodes forming an OpenMPI cluster).

[0051] In one example, when the number of processes in an OpenMPI cluster is not less than the number of tasks, this disclosure can assign one task to one process, and different tasks are assigned to different processes, that is, there is a one-to-one relationship between processes and tasks.

[0052] In another example, when the number of processes in an OpenMPI cluster is less than the number of tasks, this disclosure can also assign two or more tasks to a process, that is, different tasks can be assigned to the same process, that is, there can be a one-to-many relationship between processes and tasks.

[0053] In one example, this disclosure can employ various strategies to implement task allocation. For instance, an average allocation strategy can be used to distribute multiple tasks evenly among processes in the OpenMPI cluster. For example, if the OpenMPI cluster contains multiple processes, and the number of processes is not less than the number of tasks to be allocated, this disclosure uses an average allocation strategy to distribute multiple tasks among multiple different processes in the OpenMPI cluster. Since the task sender allocates different processes to any two tasks, the task receiver receives and executes only one task through a single process.

[0054] This disclosure adopts an average allocation strategy for task distribution, which helps to avoid the phenomenon of uneven process load in the OpenMPI cluster and helps to ensure that the resources of all nodes (such as all compute nodes) in the OpenMPI cluster are used in a balanced manner. This helps to avoid the degradation of the system performance of the OpenMPI cluster and the waste of computing resources due to low utilization.

[0055] This disclosure provides a specific example of assigning multiple tasks to multiple different processes based on OpenMPI, such as... Figure 3 As shown.

[0056] Figure 3 In the middle, S300, obtain the total number of processes in the OpenMPI cluster.

[0057] In this disclosure, all processes in the OpenMPI cluster typically have their own index value. In one example, this disclosure may sequentially number all processes in the OpenMPI cluster, thus giving each process a sequential number, which can be used as the process's index value. The process index value can also be called the process identifier. The process index value is unique; that is, the index values ​​of any two processes in S200 are different, and the index values ​​of any two processes in the OpenMPI cluster are also different.

[0058] The index value of each process in this disclosure can be represented by the process subscript or suffix. For example, if the OpenMPI cluster includes M processes (M is an integer greater than 1), and the index values ​​of these M processes are 0 to M-1, then these M processes can be represented as rank0, rank1, ... and rank M-1 This can also be represented as rank0, rank1, ..., and rankM-1. Optionally, this disclosure can obtain the total number of processes in the OpenMPI cluster by calling the corresponding function in OpenMPI. This disclosure does not limit the specific implementation method for obtaining the total number of processes.

[0059] S301. Based on the OpenMP (Open Multi-Processing) multi-threaded approach, calculate the difference between the index value of each task and the total number of processes and the first predetermined value, and perform modulo operation to obtain multiple remainders.

[0060] The modulo operation performed on each task in this disclosure can be parallelized using a multi-threaded approach based on OpenMP. OpenMP, in this disclosure, refers to a technique that enables parallel computing on a multi-core processor within a single computer and accelerates computation by sharing memory among multiple threads within the same program.

[0061] In a concrete example, this disclosure can create threads based on the number of tasks, ensuring the number of threads matches the number of tasks. Each thread performs a modulo operation once for each task. S301 of this disclosure can also be described as follows: For any task, a thread performs a modulo operation on the difference between the task's index value and the total number of processes and a first predetermined value (a non-zero positive integer), obtaining a remainder. This task corresponds to this remainder. Since there exists a process in the OpenMPI cluster, and the process's index value is this remainder, the task in this disclosure can be mapped to a unique process in the OpenMPI cluster through this remainder. The first predetermined value in this disclosure can be set according to actual needs; for example, the first predetermined value can be 1.

[0062] In one example, there are N tasks that need to be assigned processes, and the total number of processes obtained by S300 is M. If we represent the N tasks as task0, task1, ..., task... N-1 And represent the M processes as rank0, rank1, ... and rank M-1 For task i (where i is an integer greater than or equal to 0 and less than N), for the task i The modulo operation can be expressed by the following formula (1):

[0063] X=i%(mpiSize-1) Formula (1)

[0064] In the above formula (1), the first predetermined value is 1, mpiSize equals the total number of processes M in the OpenMPI cluster, i is the index value of the task, and X is the value for the task. i Calculate the remainder obtained.

[0065] This disclosure can utilize N threads to perform the calculation operation of the above formula (1), thereby obtaining the index value of the process allocated to each task in parallel.

[0066] S302. Assign each task to the process whose index value corresponds to the remainder.

[0067] Since each task corresponds to a remainder, and the remainder is usually the index value of a process, the remainder can be used to assign a task to a process. For example, according to the above formula (1), the i-th task is assigned to the process with the index value X, i.e., rank. x .

[0068] This disclosure utilizes a first predetermined value for modulo operation and uses the remainder to determine the process corresponding to the task. This not only helps to evenly distribute all tasks to processes in the OpenMPI cluster, making the process load as balanced as possible, but also prevents the task sender from sending tasks to itself.

[0069] S201. Assign labels to multiple tasks separately.

[0070] This disclosure assigns a unique tag to each task, with different tags for different tasks. That is, a task's tag is unique within a single execution of the data transmission and reception method disclosed herein. The tags in this disclosure serve to enable the task sender and receiver to perform a handshake operation based on the tag. The task sender and receiver should communicate on pre-defined tags, thereby achieving accurate data transmission and reception processing for both parties.

[0071] In one example, the operation of assigning labels to all tasks in this disclosure can be parallelized by using OpenMP multithreading, thereby obtaining the labels assigned to each task in parallel.

[0072] In one example, for any given task, this disclosure can assign two labels to the task: one label corresponding to the task's content size, and one label corresponding to the task's content. That is, this disclosure assigns a first label to the task's content size and a second label to the task's content. The first label serves to cause the corresponding process of the task receiver to wait to receive the task's content size based on the first label, and the second label serves to cause the corresponding process of the task receiver to wait to receive the task's content based on the second label.

[0073] Since the task labels in this disclosure are unique, during one execution of the data transmission and reception method of this disclosure, the first labels of any two tasks are different, the second labels of any two tasks are also different, the first label and the second label of the same task are different, and the first label and the second label of any task are also different.

[0074] In one example, the first and second labels assigned to a task can be two consecutive labels, and the first and second labels assigned to all tasks can form a numerically consecutive label sequence.

[0075] Optionally, this disclosure can be based on OpenMP multithreading to assign first and second labels to all tasks separately. For example, this disclosure can create threads based on the number of tasks, making the number of threads the same as the number of tasks, with each thread calculating the corresponding first and second labels for one task. In a specific example, this disclosure can use OpenMP's for instruction to accelerate the label allocation operation for all tasks through multithreading, parallelizing the label allocation operation for all tasks, achieving fast label allocation, and thus improving data transmission and reception efficiency.

[0076] This disclosure employs an OpenMP multi-threaded approach to assign unique first and second tags to tasks. This allows the task receiver to clearly determine the size of the task content based on the first tag, enabling it to quickly and accurately set up a buffer of the same size for the task. Consequently, the content of the task received by the task receiver based on the second tag can be quickly and accurately stored in this buffer. This approach maximizes data transmission and reception efficiency while effectively preventing buffer overflow.

[0077] Optionally, the process of assigning a first label and a second label to a task in this disclosure can be as follows: For any task, this disclosure can calculate the first label of the task based on the task's index value and a preset label starting value. Then, a label sequentially following the first label is used as the second label of the task. There are various ways to calculate the task's index value and the preset label starting value, which can be set according to the actual situation. A specific example: For any task, the product of the task's index value and a second predetermined value is obtained. The sum of the preset label starting value and the above product is used as the first label of the task, and the sum of the first label and a third predetermined value is used as the second label of the task. The preset label starting value is usually a positive integer, the second predetermined value is usually a non-zero positive integer, and the third predetermined value is usually a non-zero positive integer less than the second predetermined value.

[0078] In one example, for any task i (where i is an integer greater than or equal to 0 and less than N, and N is the number of tasks) For this task, the label allocation process can be expressed by the following formulas (2) and (3):

[0079] Tag1=TAGSTART+i*2 Formula (2)

[0080] Tag2=TAGSTART+i*2+1 Formula (3)

[0081] Here, tag1 represents the task. i The first assigned tag, tag2, indicates that it is a task. iThe second assigned tag, TAGSTART, is the preset tag start value, the second preset value is 2, and the third preset value is 1.

[0082] By introducing the task's index value and preset tag start value during the calculation of the task's first and second tags, it is beneficial to avoid conflicts between the first and second tags set for the task and tags in other programs, thereby improving the system security of the OpenMPI cluster.

[0083] In one example, the pseudocode for implementing S200 and S201 based on the OpenMP multithreading approach can be represented as follows:

[0084]

[0085] In the pseudocode above, TaskList represents a list of tasks set for all tasks. This list includes at least: the index of the task, the index of the process assigned to the task, and a label assigned to the task. The label can include at least one of a first label and a second label. Since there is a certain relationship between the first and second labels of a task (e.g., the second label is the first label plus 1), even if the task list contains only one of the first and second labels, the other label of the task can be obtained by deduction and calculation in subsequent processes where labels are needed.

[0086] In addition, this disclosure does not exclude the possibility of assigning a label to each task. That is, for any task, the task sender uses the same label when sending the content size and content of the task. In this case, the task receiver can use the data received first based on the label as the content size of the task and the data received second based on the label as the content of the task.

[0087] S202. Send the correspondence information of task, process and tag to the task receiver so that the corresponding process in each task receiver can wait to receive the corresponding task according to the tag.

[0088] Each task in this disclosure corresponds to a mapping information, and the mapping information for any two tasks is different. For example, each task corresponds to a row in a task list (TaskList). A mapping information can be represented as a one-dimensional array, which may include: the index of the task, the index of the process, and a label (such as at least one of a first label and a second label). In one example, this disclosure can use the contents of each row in the task list (TaskList) to form a mapping information. This step, by sending the mapping information of the task, process, and label to the task receiver, enables the task sender and task receiver to perform a label handshake for each task.

[0089] For any given task, the process to which the task sender sends the task's mapping information is typically different from the process assigned to the task. In one example, the index value of the process to which the task sender sends the task's mapping information may have a certain correlation with the task's index value. That is, for any given task, this disclosure can calculate the index value of the process that processes the task's mapping information based on the task's index value, and then perform the mapping information sending operation corresponding to the task according to the process with the calculated index value, thereby achieving a tag handshake between the two parties.

[0090] This disclosure can calculate the index value of the process to which the corresponding relationship information of each task is sent based on the OpenMP multithreading method, and perform the operation of sending the corresponding relationship information of each task according to the index value based on the OpenMP multithreading method. In one example, this disclosure can use the nested loop technique (collapse instruction) to implement step S202 to improve the execution speed of tag handshake.

[0091] A specific example of this disclosure sending the mapping information of tasks, processes, and tags to the task recipient is as follows: Figure 4 As shown.

[0092] Figure 4 In S400, the index values ​​of each task, the index values ​​of the processes corresponding to each task, and the first and second labels assigned to each task are respectively formed into one-dimensional arrays.

[0093] The number of one-dimensional arrays formed in this disclosure is the same as the number of tasks, and a one-dimensional array can be represented as (task i rank j , tag k ), the tag kThis includes a first tag and a second tag. In other implementations, where the task sender and task receiver have agreed in advance, the aforementioned tags... k It may include only one of the first and second labels, and the task receiver can calculate the other label based on a label in the received one-dimensional array. Alternatively, this disclosure can use OpenMP multithreading to read the contents of each row in the TaskList, thereby obtaining the one-dimensional array of all tasks in parallel.

[0094] S401. Determine the index value of the tag handshake process corresponding to each task based on the index value of each task.

[0095] The tag handshake process in this disclosure refers to the process used to implement tag handshake between the task sender and the task receiver, that is, the process used to receive and process the correspondence information between tasks, processes and tags.

[0096] For any given task, the tag handshake process corresponding to that task is usually different from the process assigned to that task, and the index value of the tag handshake process corresponding to that task usually has a certain correlation with the index value of the task. For example, for any given task, the index value of the tag handshake process corresponding to that task is the sum of the index value of the task and a predetermined value (a non-zero positive integer, such as 1).

[0097] S402, based on the OpenMP multi-threaded approach, sends the one-dimensional array corresponding to each task according to the index value of each tag handshake process.

[0098] A concrete example is for any task (such as task) i In this regard, the task sender will assign the task (such as a task) to the task sender. i The index value (e.g., i) of the task (e.g., task) iThe index value of the corresponding process, as well as the first and second tags assigned to the task (the tags are used to identify the task in inter-process communication), are sent to the process whose index value is the sum of the index value of the task (such as i) and a predetermined value (such as 1). The tag handshake process can be implemented based on inter-process communication (IPC). This involves sending the task's index and corresponding tags to the appropriate process via IPC. The receiving process (the process that assigned the task) then waits to receive relevant task information (such as task size and content) based on the first and second tags in the mapping information. For example, after process `ranki+1` receives the one-dimensional array, it can use IPC to notify the task's index (e.g., `i`) and the assigned first and second tags to the process that assigned the task. This allows the task-assigning process to know the task's index and corresponding tags, and thus wait to receive the task's size based on the first tag and the task's content based on the second tag. Employing OpenMP multithreading and IPC technology during the tag handshake process facilitates a fast and accurate implementation.

[0099] S203. Based on the correspondence information between tasks and tags, and using OpenMP multi-threading, send the content size of the task to each task receiver so that the corresponding process in each task receiver can set up a buffer according to the content size it receives.

[0100] In this disclosure, the content size of a task can be considered as the size of the cache space required by the task receiver when storing the received task content in a cache area. For any given task, the task sender of this disclosure can generate a message based on the task's first tag and the task's content size, and send the message to the task receiver. Since the corresponding process in the task receiver is in a waiting-to-receive state based on the first tag and the second tag, the process can receive the message based on the first tag and obtain the task's content size in the message. Therefore, the process can set up a cache area with the same content size as the task based on the obtained task content size. This cache area can be considered as the cache area corresponding to the first tag.

[0101] In one example, this disclosure can employ an OpenMP-based multithreaded asynchronous sending method to send the content size of each task. This OpenMP-based multithreaded asynchronous sending method refers to the task sender using OpenMP instructions (such as `for` commands) to perform multithreaded data transmission, without the task sender blocking and waiting for the transmission result. Specifically, for any given task, one thread in the task sender can, based on the correspondence between the task and its first tag, send a message generated using the task's content size and its first tag to the task's receiver using the OpenMP multithreaded asynchronous sending method. This disclosure can create separate threads for all tasks, one thread corresponding to one task. For any given task, this thread generates a message carrying the task's corresponding first tag and content size, and sends this message to the task receiver. Each thread corresponding to a task can execute its operations in parallel. After sending the content size of each task, the task sender can wait to receive the buffer allocation execution results returned by each task receiver based on the first tags it holds for each task. Since the processes in each task receiver in this disclosure receive the content size of the task based on the first tag, this disclosure does not need to pay attention to the order in which each task receiver receives the content size of the task. By using the asynchronous sending method of OpenMP multi-threading to send the content size of each task, it is beneficial to achieve rapid distribution of the content size of each task, thereby helping to ensure data transmission and reception efficiency.

[0102] S204. Based on the correspondence information between tasks and tags, using OpenMP multi-threading, send the contents of multiple tasks to each task receiver, so that the corresponding processes in each task receiver can receive the tasks according to the tags and store them in the corresponding buffers.

[0103] The content of a task in this disclosure can be considered as the task itself, such as all the instructions contained in the task. For any given task, the task sender of this disclosure can generate a message based on the second tag of the task and the content of the task, and send the message to the task receiver. Since the corresponding process in the task receiver is in a waiting state based on the first tag and the second tag, the process can receive the message based on the second tag and obtain the content of the task carried in the message. Thus, the process can store the obtained task content in a buffer area pre-set based on the first tag.

[0104] In one example, this disclosure can employ an asynchronous sending method based on OpenMP multithreading to send the content of each task. Specifically, for any given task, one thread in the task sender can, based on the correspondence between the task and the second tag, send a message generated using the content and second tag of that task to the task receiver using the asynchronous sending method of OpenMP multithreading. This disclosure can create separate threads for all tasks, with one thread corresponding to one task. For any given task, the thread generates a message carrying the second tag and content of that task and sends the message to the task receiver. Threads corresponding to all tasks can execute their respective operations in parallel. After sending the content of each task, the task sender can wait to receive the task execution results returned by each task receiver based on the second tags it holds for each task. Furthermore, the process used by the sender to send the content of a task can be determined based on the task's index value. For example, the index value of the process sending the content of the i-th task can be the sum of i and a predetermined value (such as 1). Since the processes in each task receiver in this disclosure receive the task content based on the second tag, this disclosure does not need to focus on the order in which each task receiver receives the task content. By using the asynchronous sending method of OpenMP multithreading to send the content of each task, it is beneficial to achieve rapid distribution of the content of each task, thereby helping to ensure data transmission and reception efficiency.

[0105] In one example, this disclosure uses an asynchronous sending method based on OpenMP multithreading and employs nested loop technology. The pseudocode for implementing step S204 can be represented as follows:

[0106]

[0107]

[0108] This disclosure assigns tags and processes to all tasks and sends the correspondence information of tasks, processes, and tags to each task receiver, enabling the task sender and receiver to perform a tag handshake for data transmission and reception. Both the task sender and receivers can utilize tags and OpenMP multithreading to control the size and transmission / reception of task content. Since the processes assigned to tasks in the receivers can use OpenMP multithreading to quickly and accurately set up a buffer of the same size as the task content received from the sender, the receiver processes can use OpenMP multithreading to quickly and accurately store the task content received from the sender based on tags in the designated buffer. This ensures data transmission and reception efficiency while effectively preventing buffer overflow. Therefore, the technical solution provided by this disclosure enriches multithreaded data transmission and reception technologies and improves the data transmission and reception security of the system.

[0109] Figure 5 This is a flowchart of another embodiment of the multi-threaded data transmission and reception method disclosed herein. Figure 5 The method shown is executed on the task receiver (also known as the task executor), which is typically an OpenMPI-based computing node. This method mainly includes: S500, S501, S502, S503, and S504. The following section discusses... Figure 5 Each step in the process will be explained separately.

[0110] S500: Receive the correspondence information of task, process and tag from the task sender.

[0111] In this step, the process refers to the process assigned to the task by the task sender, and the label refers to the label assigned to the task by the task sender. The mapping information in this step can be sent from the task sender to the label handshake process, and then provided to the task receiver by the label handshake process via inter-process communication. This mapping information indicates that the corresponding process in the task receiver should wait to receive the size and content of a task based on the corresponding label. The association between the task index, process index, and label in this mapping information can be found in the above section on... Figure 2 The relevant steps described in the previous section will not be described in detail here.

[0112] S501. Based on the above correspondence information, the corresponding OpenMPI-based process is placed in the waiting-to-receive state on the corresponding tag.

[0113] Specifically, the corresponding OpenMPI-based process in this step refers to the process assigned by the task sender to the task receiver for the task they are responsible for. This process, after the tag handshake process announcement, waits to receive the task size and content from the task sender, based on its held first and second tags.

[0114] S502. When the above process receives the content size of the task from the task sender based on the tags in the above correspondence information and the OpenMP multi-threading method, it sets up a buffer according to the content size of the task.

[0115] Optionally, when a process receives a message containing the first tag and the task's content size based on its held first tag, it can obtain the task's content size from the message and perform a buffer setting operation. The size of the buffer set by the process is typically the same as the task's content size. This buffer can be considered the buffer corresponding to the first tag / second tag. After successfully performing the buffer setting operation, the process can return the buffer setting result to the task sender based on the first tag, such as by including the first tag and the buffer setting result in a response message and sending that response message to the task sender. The task sender waits to receive the buffer setting results returned by each task receiver based on the first tags it holds for each task.

[0116] S503. When the above process receives the content of the task from the task sender based on the tags in the above correspondence information and using the OpenMP multi-threading method, it stores the content of the task in the above buffer.

[0117] Optionally, when a process receives a message containing the second label and the size of the task based on the second label in its corresponding relationship information, it can obtain the content of the task from the message and store the content of the task in the cache area corresponding to the first label / second label.

[0118] S504. The process executes the task according to the content of the task stored in the above-mentioned cache area, and returns the execution result of the task to the task sender according to the label in the above-mentioned correspondence information.

[0119] Optionally, after executing a task based on the content of the task stored in the cache, the process can return the task execution result to the task sender based on the second tag assigned to the task. This can be achieved by including the second tag and the task execution result in a response message and sending that message to the task sender. The task sender then waits to receive the task execution results returned by each task receiver based on the second tags it holds for each task.

[0120] The pseudocode for an example of all data transmission and reception operations performed by the task receiver in this disclosure can be represented in the following form:

[0121]

[0122] In this disclosure, the task receiver performs a tag handshake with the task sender using the correspondence information between tasks, processes, and tags. This allows the task receiver to wait for the assigned task's size and content using the tag. By employing OpenMP multithreading to perform the receiving operation, the size of the task content and the receiving speed are improved. Since the process in the task receiver has a buffer set up based on the content size of the task corresponding to the tag, regardless of whether the task content is received in the expected order, it can be accurately stored in the buffer corresponding to the tag, thus avoiding buffer overflow issues. Therefore, the technical solution provided in this disclosure is beneficial for enriching multithreaded data transmission and reception technologies and improving the data transmission and reception security of the system.

[0123] A specific implementation flow of the multi-threaded data transmission and reception method disclosed herein can be as follows: Figure 6 As shown.

[0124] Figure 6 In the middle, S600, the steps to start this process.

[0125] S601, the master node (also known as the OpenMPI master node), organizes each task to be sent into a one-dimensional array. The contents of a one-dimensional array can be all the information contained in a task. The one-dimensional arrays of all tasks to be sent can form a two-dimensional array totalTask.

[0126] S602. The master node assigns processes and labels to all tasks currently awaiting transmission. For example, the master node uses an average allocation strategy, distributing all tasks evenly across processes in the OpenMPI cluster. Typically, the master node assigns different processes to any two tasks. Another example is that the master node uses the index value of each task and a preset label starting value to calculate and assign a first label and a second label to all tasks.

[0127] S603. The master node and each compute node perform a tag handshake. For example, the master node starts an OpenMP multithread to calculate the index value of the process to which the corresponding relationship information of each task is sent, and uses the OpenMP multithread to perform the operation of sending the corresponding relationship information of each task according to the obtained index value, thereby realizing the tag handshake.

[0128] S604. The corresponding processes in each compute node wait to receive data on their designated tags. Here, the corresponding process refers to the process assigned to the task by the master node. The designated tag is the tag in the tag handshake operation described above; the designated tag can include a first tag and a second tag. The data can be in the form of a message, specifically a message carrying the content size of the first tag and the task, or a message carrying the content of the second tag and the task, etc.

[0129] S605. When each computing node detects the arrival of a specified tag (such as the first tag or the second tag), it starts OpenMP multithreading, such as by using the OpenMP for instruction to start OpenMP multithreading.

[0130] S606. Each compute node uses OpenMP multithreading to receive the task content size at a specified tag (e.g., the first tag), sets up a buffer based on the task content size, and returns the buffer setting result to the master node based on the specified tag (e.g., the first tag). Each compute node uses OpenMP multithreading to receive the task content at a specified tag (e.g., the second tag), stores the task content in the buffer set based on the first tag, executes the instructions contained in the task, and returns the task execution result to the master node based on the specified tag (e.g., the second tag).

[0131] S607. The master node uses OpenMP multithreading (e.g., starting OpenMP multithreading by using the OpenMP for instruction) to send data (e.g., the size and content of each task) to the compute nodes based on the specified tags of all tasks (e.g., the first tag and the second tag of each task), and waits to receive the results returned by each compute node (e.g., buffer setting results and task execution results) on the specified tags (e.g., the first tag and the second tag of each task).

[0132] S608. When the master node detects the arrival of a specified tag (such as the first tag or the second tag), it starts OpenMP multithreading, such as by using the OpenMP for instruction to start OpenMP multithreading.

[0133] S609. The master node uses OpenMP multithreading to receive the results returned by each compute node on a specified label (such as the first or second label of all tasks), such as buffer setting results and task execution results.

[0134] S610, Steps to end this process.

[0135] Exemplary device

[0136] Figure 7This is a schematic diagram of the structure of an embodiment of the multi-threaded data transceiver device of this disclosure. The device of this embodiment can be used to implement the corresponding method embodiments of this disclosure. Figure 7 The device shown includes: a task allocation module 700, a tag allocation module 701, a first tag handshake module 702, a first sending module 703, and a second sending module 704.

[0137] The task allocation module 700 is mainly used to allocate multiple tasks to multiple processes based on OpenMPI. Optionally, the task allocation module 700 can allocate multiple tasks to multiple different processes in the OpenMPI cluster; wherein, the processes allocated to any two tasks are different. In one example, the task allocation module 700 includes: a first submodule 7001, a second submodule 7002, and a third submodule 7003. The first submodule 7001 is used to obtain the total number of processes in the OpenMPI cluster. The second submodule 7002 is used to calculate the difference between the index value of each task and the total number of processes and a first predetermined value based on the OpenMP multithreading method, and perform modulo operation to obtain multiple remainders, wherein the first predetermined value is a non-zero positive integer. The third submodule 7003 is mainly used to allocate each task to the process whose index value is the corresponding remainder. The specific operations performed by the task allocation module 700 and its submodules can be found in the above method for S200 and... Figure 3 The relevant descriptions will not be elaborated here.

[0138] The tag allocation module 701 is mainly used to allocate tags to the multiple tasks mentioned above, where different tasks have different tags. In one example, the tag allocation module 701 can allocate a first tag to the content size of multiple tasks and a second tag to the content of multiple tasks based on OpenMP multithreading. The first tags of any two tasks are different, the second tags of any two tasks are different, the first tag and second tag of the same task are different, and the first tag and second tag of any task are different. The first tag is used to make the corresponding process of the receiving party wait to receive the content size of the task based on the first tag, and the second tag is used to make the corresponding process of the receiving party wait to receive the content of the task based on the second tag. In another example, for any task, the tag allocation module 701 can calculate the first tag of the task based on the index value of the task and the preset tag start value using a single thread of OpenMP, and use the tag sequentially following the first tag as the second tag of the task. The specific operations performed by the tag allocation module 701 can be found in the description of S201 in the above method, and will not be described in detail here.

[0139] The first tag handshake module 702 is mainly used to send the correspondence information of tasks, processes, and tags to the task receivers, so that the processes in each task receiver wait to receive the corresponding tasks according to the tags. Optionally, the first tag handshake module 702 may include: a fourth submodule 7021, a fifth submodule 7022, and a sixth submodule 7023. The fourth submodule 7021 is used to form one-dimensional arrays of the index values ​​of each task, the index values ​​of the processes corresponding to each task, and the first and second tags assigned to each task. The fifth submodule 7022 is used to determine the index value of the tag handshake process corresponding to each task according to the index value of each task. The sixth submodule 7023 is used to send the one-dimensional array corresponding to each task according to the index value of each tag handshake process based on the OpenMP multi-threading method, so that the corresponding processes in the task receivers wait to receive the content size and content of the task according to the first and second tags in the correspondence information obtained by the tag handshake process; wherein, for any task, the index value of the tag handshake process corresponding to the task is different from the index value of the process assigned to the task. The specific operations performed by the first tag handshake module 702 and its constituent sub-modules can be found in the above method for S202 and... Figure 4 The relevant descriptions will not be elaborated here.

[0140] The first sending module 703 is mainly used to send the content size of the multiple tasks to each task receiver based on the correspondence information between the tasks and tags, using an OpenMP multi-threaded approach, so that the corresponding processes in each task receiver can set up buffers according to the received content size. For example, the first sending module 703 can send the content size of each task and the first tag of each task to each task receiver respectively, based on the correspondence information between the tasks and the first tag, using an OpenMP multi-threaded asynchronous sending approach. The specific operations performed by the first sending module 703 can be found in the relevant description of S203 in the above method, and will not be described in detail here.

[0141] The second sending module 704 is mainly used to send the content of the multiple tasks to each task receiver based on the correspondence information between tasks and tags, using an OpenMP multi-threaded approach. This allows the corresponding processes in each task receiver to receive the tasks according to the tags and store them in their respective buffers. For example, the second sending module 704 can send the content of each task and the second tag of each task to each task receiver based on the correspondence information between tasks and second tags, using an OpenMP multi-threaded asynchronous sending approach. The specific operations performed by the second sending module 704 can be found in the description of S204 in the above method, and will not be detailed here.

[0142] Figure 8 This is a schematic diagram of another embodiment of the multi-threaded data transceiver apparatus of this disclosure. The apparatus of this embodiment can be used to implement the corresponding method embodiments of this disclosure. Figure 8 The device shown includes: a second tag handshake module 800, a wait-to-receive module 801, a set buffer module 802, a task storage module 803, and a task execution module 804.

[0143] The second tag handshake module 800 is mainly used to receive the correspondence information between the task, process, and tag from the task sender. The specific operations performed by the second tag handshake module 800 can be found in the relevant description of S500 in the above method, and will not be elaborated upon here.

[0144] The waiting-to-receive module 801 is mainly used to control the corresponding OpenMPI-based process to be in a waiting-to-receive state on the corresponding tag, based on the above correspondence information. The specific operations performed by the waiting-to-receive module 801 can be found in the relevant description of S501 in the above method, and will not be described in detail here.

[0145] The buffer setting module 802 is mainly used to set the buffer size according to the content size of the task sent by the process when the process receives the task content size from the task sender based on the tags in the above correspondence information using the OpenMP multi-threaded method. The specific operations performed by the buffer setting module 802 can be found in the relevant description of S502 in the above method, and will not be described in detail here.

[0146] The task storage module 803 is mainly used to store the content of a task from the task sender in the cache set by the cache setting module 802 when the process receives the content of the task based on the tag in the corresponding relationship information and using the OpenMP multi-threaded method. The specific operations performed by the task storage module 803 can be found in the description of S503 in the above method, and will not be described in detail here.

[0147] The task execution module 804 is mainly used to enable the process to execute tasks according to the content of tasks stored in the cache set by the cache setting module 802, and to enable the process to return the task execution result to the task sender according to the tag in the correspondence information. The specific operations performed by the task execution module 804 can be found in the relevant description of S504 in the above method, and will not be described in detail here.

[0148] Exemplary electronic devices

[0149] The following is for reference. Figure 9 To describe an electronic device according to embodiments of the present disclosure. Figure 9 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. Figure 9 As shown, the electronic device 91 includes one or more processors 911 and memory 912.

[0150] The processor 911 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 91 to perform desired functions.

[0151] The memory 912 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, and flash memory. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 911 may execute the program instructions to implement the multi-threaded data transmission and reception methods and / or other desired functions described in the various embodiments of this disclosure above.

[0152] In one example, the electronic device 91 may further include an input device 913 and an output device 914, etc., these components being interconnected via a bus system and / or other forms of connection mechanisms (not shown). Furthermore, the input device 913 may also include, for example, a keyboard, a mouse, etc. The output device 914 can output various information to the outside. The output device 914 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0153] Of course, for the sake of simplicity, Figure 9 Only some of the components of the electronic device 91 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 91 may include any other suitable components depending on the specific application.

[0154] Exemplary computer program products and computer-readable storage media

[0155] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the multithreaded data transmission and reception methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0156] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0157] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps of the multithreaded data transmission and reception method according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0158] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples (not an exhaustive list) of a readable storage medium may include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0159] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0160] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0161] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0162] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0163] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0164] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0165] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A multi-threaded data sending and receiving method, executed on the task sender, comprising: Distribute multiple tasks to multiple processes based on the OpenMPI open message transmission interface; Tags are assigned to the multiple tasks, wherein different tasks have different tags; for any task, the tag includes a first tag and a second tag, wherein the first tag corresponds to the content size of the task, and the second tag corresponds to the content of the task; Send the correspondence information of the task, process and tag to the task receiver so that the process in each task receiver waits to receive the corresponding task according to the tag; The step of sending the correspondence information of tasks, processes, and tags to the task receiver includes: forming one-dimensional arrays of the index values ​​of each task, the index values ​​of the processes corresponding to each task, and the first and second tags assigned to each task; determining the index value of the tag handshake process corresponding to each task based on the index value of each task; and sending the one-dimensional array corresponding to each task based on the index value of the tag handshake process using OpenMP multi-threading, so that the corresponding process in the task receiver waits to receive the content size and content of the task based on the first and second tags in the correspondence information obtained by the tag handshake process; wherein, for any task, the index value of the tag handshake process corresponding to the task is different from the index value of the process assigned to the task. Based on the correspondence information between the tasks and tags, and using the multi-processing and multi-threading approach of OpenMP, the content size of the multiple tasks is sent to each task receiver, so that the corresponding process in each task receiver sets up a buffer according to the received content size. Based on the correspondence information between the tasks and tags, and using OpenMP multithreading, the contents of the multiple tasks are sent to each task receiver, so that the corresponding processes in each task receiver receive the tasks according to the tags and store them in the corresponding buffers.

2. The method according to claim 1, wherein, The method of assigning multiple tasks to multiple OpenMPI-based processes includes: Distribute multiple tasks to multiple different processes in the OpenMPI cluster; In this case, the processes assigned to any two tasks are different.

3. The method according to claim 2, wherein, The method of assigning multiple tasks to multiple different processes in an OpenMPI cluster includes: Get the total number of processes in the OpenMPI cluster; Based on the OpenMP multithreading approach, the index value of each task is calculated and moduloed by the difference between the total number of processes and a first predetermined value to obtain multiple remainders, wherein the first predetermined value is a non-zero positive integer; Each task is assigned to the process whose index value corresponds to the remainder.

4. The method according to claim 1, wherein, Assigning labels to the multiple tasks includes: Based on the OpenMP multithreading approach, a first label and a second label are assigned to the multiple tasks respectively, wherein the first label corresponds to the content size of the corresponding task, and the second label corresponds to the content of the corresponding task; In this context, the first labels of any two tasks are different, the second labels of any two tasks are different, the first label and the second label of the same task are different, and the first label and the second label of any task are different. The first label is used to make the corresponding process of the receiver wait to receive the content size of the task based on the first label, and the second label is used to make the corresponding process of the receiver wait to receive the content of the task based on the second label.

5. The method according to claim 4, wherein, Assigning a first label and a second label to the multiple tasks respectively includes: For any given task, based on the OpenMP multithreaded approach, the thread corresponding to the task calculates the first tag of the task according to the index value of the task and the preset tag start value, and uses the tag that follows the first tag in sequence as the second tag of the task.

6. The method according to claim 4 or 5, wherein, Based on the correspondence information between the tasks and tags, and using OpenMP multithreading, the content sizes of the multiple tasks are sent to each task receiver, including: Based on the correspondence information between the tasks and the first tag, and using the asynchronous sending method of OpenMP multi-threading, the content size of each task and the first tag of each task are sent to the respective task receivers. Based on the correspondence information between the tasks and tags, and using OpenMP multithreading, the content of the multiple tasks is sent to each task receiver, including: Based on the correspondence information between the tasks and the second tags, and using the asynchronous sending method of OpenMP multithreading, the content of each task and the second tag of each task are sent to the respective task receivers.

7. A multi-threaded data sending and receiving method, which is executed on the task receiver, including: Receive the correspondence information of task, process and tag from the task sender, wherein the correspondence information includes the index value of the task, the index value of the process assigned to the task, and the first tag and the second tag assigned to the task. The first tag corresponds to the content size of the task, the second tag corresponds to the content of the task, and the correspondence information is provided to the corresponding process in the task receiver by the tag handshake process based on inter-process communication. Based on the corresponding relationship information, the corresponding OpenMPI-based process, after the tag handshake process notification, waits to receive the content size and content of the task based on the first and second tags it holds; When the process receives the content size of the task from the task sender based on the first tag and using OpenMP multithreading, it sets up a buffer according to the content size of the task. When the process receives the content of a task from the task sender based on the second tag and using the OpenMP multithreading method, it stores the content of the task in the buffer. The process executes the task according to the content of the task stored in the cache, and returns the execution result of the task to the task sender according to the second tag.

8. A multi-threaded data transceiver device, comprising: The task allocation module is used to assign multiple tasks to multiple OpenMPI-based processes; The tag assignment module is used to assign tags to the multiple tasks respectively, wherein different tasks have different tags; for any task, the tag includes a first tag and a second tag, the first tag corresponds to the content size of the task, and the second tag corresponds to the content of the task; The first tag handshake module is used to send the correspondence information of tasks, processes, and tags to the task receivers, so that the processes in each task receiver wait to receive the corresponding tasks according to the tags. The first tag handshake module includes: a fourth submodule, used to form one-dimensional arrays of the index values ​​of each task, the index values ​​of the processes corresponding to each task, and the first and second tags assigned to each task; a fifth submodule, used to determine the index value of the tag handshake process corresponding to each task based on the index value of each task; and a sixth submodule, used to send the one-dimensional array corresponding to each task based on the index value of the tag handshake process using an OpenMP multi-threaded approach, so that the corresponding processes in the task receivers wait to receive the content size and content of the task according to the first and second tags in the correspondence information obtained by the tag handshake process. For any given task, the index value of the tag handshake process corresponding to that task is different from the index value of the process assigned to that task. The first sending module is used to send the content size of the multiple tasks to each task receiver based on the correspondence information between the tasks and tags and using the OpenMP multi-threading method, so that the corresponding process in each task receiver sets up a buffer according to the received content size. The second sending module is used to send the contents of the multiple tasks to each task receiver based on the correspondence information between the tasks and tags, using the OpenMP multi-threading method, so that the corresponding processes in each task receiver receive the tasks according to the tags and store them in the corresponding buffers.

9. The apparatus according to claim 8, wherein, The task allocation module is specifically used for: Distribute multiple tasks to multiple different processes in the OpenMPI cluster; In this case, the processes assigned to any two tasks are different.

10. The apparatus according to claim 9, wherein, The task allocation module includes: The first submodule is used to obtain the total number of processes in the OpenMPI cluster; The second submodule is used to calculate the difference between the index value of each task and the total number of processes and a first predetermined value based on the OpenMP multithreading method, and perform a remainder operation to obtain multiple remainders, wherein the first predetermined value is a non-zero positive integer; The third submodule is used to assign each task to the process whose index value corresponds to the remainder.

11. The apparatus according to claim 8, wherein, The tag allocation module is specifically used for: Based on the OpenMP multithreading approach, a first label and a second label are assigned to the multiple tasks respectively, wherein the first label corresponds to the content size of the corresponding task, and the second label corresponds to the content of the corresponding task; In this context, the first labels of any two tasks are different, the second labels of any two tasks are different, the first label and the second label of the same task are different, and the first label and the second label of any task are different. The first label is used to make the corresponding process of the receiver wait to receive the content size of the task based on the first label, and the second label is used to make the corresponding process of the receiver wait to receive the content of the task based on the second label.

12. The apparatus according to claim 11, wherein, The tag allocation module is specifically used for: For any given task, based on the OpenMP multithreaded approach, the thread corresponding to the task calculates the first tag of the task according to the index value of the task and the preset tag start value, and uses the tag that follows the first tag in sequence as the second tag of the task.

13. The apparatus according to claim 11 or 12, wherein, The first sending module is specifically used for: Based on the correspondence information between the tasks and the first tag, and using the asynchronous sending method of OpenMP multi-threading, the content size of each task and the first tag of each task are sent to the respective task receivers. The second sending module is specifically used for: Based on the correspondence information between the tasks and the second tags, and using the asynchronous sending method of OpenMP multithreading, the content of each task and the second tag of each task are sent to the respective task receivers.

14. A multi-threaded data transceiver device, comprising: The second tag handshake module is used to receive the correspondence information of task, process and tag from the task sender. The correspondence information includes the index value of the task, the index value of the process assigned to the task, and the first tag and the second tag assigned to the task. The first tag corresponds to the content size of the task, and the second tag corresponds to the content of the task. The correspondence information is provided to the corresponding process in the task receiver by the tag handshake process based on inter-process communication. The waiting to receive module is used to, according to the correspondence information, enable the corresponding OpenMPI-based process to wait to receive the content size and content of the task based on the first and second tags it holds after the tag handshake process is notified. The buffer module is configured to enable the process to set up a buffer based on the content size of the task when the process receives the content size of the task from the task sender based on the first tag and using OpenMP multithreading. The task storage module is used to enable the process to store the content of the task in the cache area when the process receives the content of the task from the task sender based on the second tag and in the OpenMP multi-threaded mode. The task execution module is used to enable the process to execute the task according to the content of the task stored in the cache, and to enable the process to return the execution result of the task to the task sender according to the second tag.

15. A computer-readable storage medium storing a computer program for performing the method of any one of claims 1-7.

16. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method of any one of claims 1-7.

Images