A dynamic circular queue implementation GPU multi-stream data synchronization method

Abstract

This invention specifically relates to a method for synchronizing multi-stream data in a GPU using a dynamic circular queue, belonging to the field of radar signal processing. Addressing the problem of out-of-order results caused by inconsistent pace in GPU multi-stream parallel processing, this method first constructs a shared memory queue to receive the processing results from each stream. After adding a mutex lock to ensure data consistency, the results are stored in a circular queue. Reports within the queue are sorted and organized by timestamp and sent to a dynamic scheduling management module. Abnormal reports are eliminated through timestamp comparison. A dynamic scheduling and anomaly protection mechanism is constructed by combining a timestamp difference threshold and an error counter, enabling the on-demand, ordered output of multi-stream processing results. This invention achieves loose coupling between multiple streams, improves program reusability, and ensures timely and robust reporting of processing results. It is suitable for scenarios such as radar signal processing where high data orderliness and reliability are required.

Description

Technical Field

[0001] This invention relates to the field of digital signal processing in radar signal processing, specifically to a method for GPU multi-stream data synchronization using a dynamic circular queue. This invention not only achieves decoupling of multiple streams but also solves the problem of out-of-order processing results, making it widely applicable in radar signal processing and laying the foundation for future intelligent radar systems. Background Technology

[0002] Intelligent radar signal processing integrates advanced technologies such as artificial intelligence, big data, and cloud computing, endowing radar systems with autonomous perception, analysis, decision-making, and optimization capabilities. This requires constructing data-driven knowledge graphs based on massive amounts of data and advanced data processing technologies, typically employing algorithms such as machine learning, deep learning, and edge intelligence. Radar systems, facing rapidly changing battlefield environments, demand rapid response capabilities, thus requiring powerful computing power and computational architecture. Distributed computing architectures based on CPU general-purpose processing blades are necessary to address the high real-time processing demands of massive data in radar signal processing scenarios. However, the communication latency introduced by node expansion poses a significant challenge to these real-time requirements. Furthermore, the expansion of blades also introduces issues related to size, power consumption, and cost. Therefore, reducing the number of processing nodes, increasing the computing power of a single node, and building new processing architectures using powerful computing platforms are key research areas for future solutions. A CPU+GPU heterogeneous processing platform is one option. CPUs excel in logic control and can implement complex algorithms in data processing; GPUs excel in parallel computing and, as coprocessors, can accelerate large-scale matrix operations and Fourier transforms in backend processing. GPU-based multi-stream development can significantly enhance computing power, but multi-stream processing results often cannot be output in the required order, failing to meet the needs of certain radar operating scenarios. Therefore, a data synchronization method based on a dynamic circular queue is proposed for multi-stream processing. This method uses a shared memory queue to receive the processing results sent by each stream and stores the multi-stream processing results in the shared memory into the circular queue in sequence. By utilizing the system timestamp information attached to each stream processing result, a dynamic scheduling mechanism based on timestamp management is constructed. This mechanism enables the on-demand and orderly output of multi-stream processing results.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] To address the issue of inconsistent processing speeds in multi-stream radar signal processing, leading to out-of-order results from parallel processing, this invention proposes a dynamic circular queue method for GPU multi-stream data synchronization. Shared memory is used to receive the processing results from each stream, and these results are sequentially stored in a circular queue. A dynamic scheduling mechanism based on timestamp management is constructed using the system timestamp information attached to each stream's processing results. This mechanism enables on-demand, ordered output of multi-stream processing results. This method not only decouples the processing between multiple streams but also achieves timely and robust reporting of processing results based on an anomaly protection mechanism.

[0005] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0006] According to a first aspect of the present invention, a method for implementing GPU multi-stream data synchronization using a dynamic circular queue is provided, the method comprising: Step 1: Construct a shared memory queue to receive processing results from multiple processing streams from the GPU; check in real time whether the shared memory queue is empty. If it is not empty, store all processing results in the shared memory queue into a circular queue. Step 2: Organize the data in the circular queue, and determine the method of sending it to the dynamic scheduling management module based on the number of frame reports in the circular queue; Step 3: In the dynamic scheduling management module, determine whether this is the first transmission after system startup; if so, directly send the current frame report and record the timestamp of the frame report as the transmission timestamp; otherwise, read the frame reports sequentially according to the order of the circular queue, extract the timestamp of the current frame report as the current timestamp, and if the current timestamp is less than or equal to the transmission timestamp, delete the frame report from the circular queue; traverse the circular queue until the current timestamp of all frame reports in the queue is greater than the transmission timestamp; Step 4: Read the remaining frame reports in the circular queue in sequence, record the timestamp of the current frame report being read as the current timestamp, and calculate the difference between the current timestamp and the sending timestamp; by comparing the timestamp difference with the timestamp difference threshold, construct a dynamic scheduling mechanism based on timestamp management to realize the output of frame reports on demand in the order of timestamps.

[0007] In some exemplary embodiments, mutex locks are applied to the read and write operations of the shared memory queue and the write operation of the circular queue to ensure data consistency.

[0008] In some exemplary embodiments, determining the method of sending frames to the dynamic scheduling management module based on the number of frame reports in the circular queue specifically includes: The number of frame reports in the circular queue is determined. If there is only one frame, it is directly sent to the dynamic scheduling management module. If there is more than one frame, the frame reports in the queue are sorted in ascending order of timestamp information attached to each frame report, and the sorted frame reports are sent to the dynamic scheduling management module.

[0009] In some exemplary embodiments, the step of constructing a dynamic scheduling mechanism based on timestamp management by comparing the timestamp difference with a timestamp difference threshold, and realizing the on-demand output of frame reports in timestamp order, specifically involves: If the timestamp difference equals the preset timestamp difference threshold, then send the frame report, update the sending timestamp to the current timestamp, and clear the timestamp error counter; if the difference does not equal the timestamp difference threshold, then increment the timestamp error counter; if the value of the timestamp error counter reaches the preset maximum error count threshold, then increment the sending timestamp by the timestamp difference threshold and clear the timestamp error counter; repeat this step until the circular queue is empty.

[0010] In some exemplary embodiments, the preset timestamp difference threshold is 1.

[0011] In some exemplary embodiments, the preset maximum error count threshold is 4.

[0012] According to a second aspect of the present invention, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the GPU multi-stream data synchronization method using a dynamic circular queue as described in the first aspect.

[0013] According to a third aspect of the present invention, a computer program product is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the dynamic circular queue method for GPU multi-stream data synchronization described in the first aspect above.

[0014] According to a fourth aspect of the present invention, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to implement the GPU multi-stream data synchronization method described in the first aspect by executing the executable instructions.

[0015] The data synchronization method based on a dynamic circular queue provided by the embodiments of the present invention offers an integrated solution to address core pain points in radar signal processing, such as out-of-order processing of GPU multi-stream parallel processing results, high inter-stream coupling, and insufficient robustness under abnormal scenarios. It possesses the following significant beneficial effects: 1. Precisely solves the problem of out-of-order multi-stream processing and achieves on-demand ordered output: By constructing a full-process mechanism of "shared memory queue reception + circular queue sorting + timestamp dynamic scheduling", and using the unique timestamp attached to the processing result of each stream as the core basis, the orderly arrangement of out-of-order processing results of multiple streams is achieved. Regardless of the inconsistent output pace of each stream due to factors such as data volume fluctuations and operating system scheduling jitter, it can ensure that frame reports are reported on demand in ascending order of timestamp, perfectly meeting the core requirements of radar signal processing of "strong real-time and unique time series", and filling the application gap of existing multi-stream synchronization technology in dynamic scenarios.

[0016] 2. Achieving loosely coupled multi-stream design to enhance system flexibility and reusability: This invention uses a shared memory queue as the intermediate carrier for receiving multi-stream data. Each stream does not need to pay attention to the execution status of other streams; it only needs to independently complete its own data processing and write the "result + timestamp" to the shared memory queue, completely breaking the coupling relationship of "stream dependency binding" in traditional multi-stream synchronization schemes. This decentralized reception and centralized scheduling design not only reduces the complexity of program development and maintenance and improves code readability, but also allows the multi-stream processing logic to be independently extended or replaced, greatly enhancing the system's adaptability to different processing scenarios and different stream configurations, and significantly improving program reusability.

[0017] 3. Establish multiple safeguard mechanisms to enhance system robustness and data reliability: By applying mutex locks to read and write operations on shared memory queues and circular queues, data conflicts, loss, or incompleteness caused by concurrent access from multiple streams are effectively avoided, ensuring data consistency. A timestamp comparison mechanism is introduced to automatically remove expired error reports with timestamps less than or equal to the sent timestamp, ensuring the validity of the output data; The innovative design of the "timestamp error counter + dual threshold control" anomaly protection logic can prevent the system from falling into an infinite loop when the timestamp difference does not meet expectations. This not only solves the scheduling blockage or information loss problem caused by abnormal data in traditional solutions, but also adapts to the high reliability requirements of the complex battlefield environment of radar, significantly improving the system's versatility and robustness.

[0018] Balancing parallel computing power and processing efficiency to meet stringent real-time requirements: This invention achieves multi-stream synchronization and ordered output without sacrificing the core advantages of GPU multi-stream parallel processing. The dual-queue architecture has a clear division of labor: the shared memory queue focuses on data reception buffering, while the circular queue focuses on sorting and scheduling. Mutex locks are only applied to critical queue read / write operations, avoiding the parallel efficiency loss caused by global scheduling locks. The loosely coupled multi-stream design allows the GPU's parallel computing power to be fully utilized, and the anomaly protection mechanism reduces invalid waiting time. Ultimately, it achieves an organic unity of "high parallel computing power," "ordered output," and "high-timeliness reporting," fully meeting the stringent time requirements of time-sensitive systems such as radar signal processing.

[0019] 4. Wide range of applicable scenarios and strong technical promotion value: This invention is not only applicable to scenarios such as phased array radar back-end signal processing in the field of radar signal processing, but its core design concept of "dual queue architecture + timestamp dynamic scheduling + anomaly fault tolerance" can be seamlessly transferred to other fields that require GPU multi-stream parallel processing and have requirements for the orderliness and robustness of results, such as video encoding and decoding, satellite remote sensing data processing, and large-scale scientific computing. It provides a general solution to the multi-stream synchronization problem under CPU+GPU heterogeneous architecture and has an important role in promoting the development of related technical fields.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 A flowchart illustrating the steps of the method of the present invention; Figure 2 To illustrate the data input allocation diagram of the present invention; Figure 3 To illustrate the shared memory queue read diagram of the present invention; Figure 4 This is a schematic diagram illustrating the abnormal handling protection of the circular queue according to the present invention; Figure 5 To illustrate the abnormal transmission protection of the present invention; Figure 6 This is a simulation diagram of the present invention. Detailed Implementation

[0023] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0024] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0025] To address the shortcomings and deficiencies of existing technologies, this example embodiment provides a method for GPU multi-stream data synchronization using a dynamic circular queue. By using a circular queue, recording and comparing timestamp information and handling anomaly protection, the on-demand ordered output of multi-stream processing results is achieved. This invention includes the following steps: Step 1: Construct a shared memory queue to receive data from each stream processing result. Check the shared memory queue in real-time to see if it's empty. If not empty, store all processing results in the shared memory queue into a circular queue, ready to be sent. Mutex locks are required for reading and writing to both the shared memory queue and the circular queue to ensure that access to the queue is unique at any given time, thus ensuring data consistency.

[0026] Step 2: Organize the data. First, determine if the circular queue contains only one report frame. If it contains only one frame, send it directly to the dynamic scheduling management module. If it contains more than one frame, sort the reports in the queue according to their timestamps from smallest to largest, and then send the sorted reports to the dynamic scheduling management module.

[0027] Step 3: In the dynamic scheduling management module, determine if the current transmission status is the first transmission since the system powers on. If it is the first transmission, transmit directly and record the frame timestamp as the transmission timestamp. Otherwise, read the reports sequentially in the circular queue, retrieve the current timestamp from the report, and determine if the current timestamp is less than or equal to the transmission timestamp. If it is less than the transmission timestamp, delete the frame report from the circular queue; otherwise, do not process it. Iterate through all reports until the timestamps of all reports in the circular queue meet the requirements.

[0028] Step 4: Read out the reports that meet the requirements one by one, and record the timestamp of the current report read out as the current timestamp. Subtract the sending timestamp from the current timestamp to get the timestamp difference. If the timestamp difference equals the timestamp difference threshold... If the frame is not reported, the transmission timestamp will be updated to the current timestamp, and the timestamp error counter will be reset to zero. If the timestamp difference is not equal to the timestamp difference threshold... If the timestamp error counter is greater than or equal to the maximum error count threshold, then increment the timestamp error counter by one. Then add the sending timestamp. At the same time, reset the timestamp error counter to zero. Repeat the above process until the circular queue is empty.

[0029] To further explain, this invention uses a comparison mechanism between the current timestamp and the sending timestamp to eliminate abnormal reports.

[0030] To further explain, this invention enables the circular queue to be sorted in ascending order of timestamps by constructing timestamps.

[0031] To further explain, this invention uses timestamp difference and timestamp difference threshold. By comparing and judging, a dynamic scheduling mechanism for timestamp management was constructed, which enabled the frame reports to be output on demand in timestamp order.

[0032] To further explain, this invention implements abnormal situation protection by setting a timestamp error counter, ensuring that the transmission does not fall into an infinite loop.

[0033] This invention proposes a data synchronization method based on a dynamic circular queue, which not only achieves decoupling of multiple streams but also solves the problem of out-of-order processing results. It has the following innovative features: A dynamic scheduling mechanism based on timestamp management was constructed to achieve on-demand and orderly output of multi-stream processing results.

[0034] Achieve loose coupling between multiple streams, improving program readability and reusability; The anomaly protection-based processing mechanism enhances the system's versatility and robustness.

[0035] The steps in this exemplary embodiment will now be described in more detail with reference to the accompanying drawings and examples.

[0036] This example demonstrates a processing platform built using one CPU (Xeon E5) and one GPU (NVIDIA P6). Without loss of generality, the analysis and explanation will focus on the back-end signal processing flow of a phased array radar. Based on the processing requirements of this radar signal processing system, the number of receive buffers will be configured. The number of multi-stream processing flows is The timestamp difference threshold is Timestamp error counter threshold The specific implementation method is as follows: 1. The beam data processed by the radar front-end is interconnected with the processing platform via optical fiber. Using the SRIO protocol, the radar front-end sends the beam data to the CPU processing blades of the processing platform. The CPU processing blades buffer the data and process it at CPI intervals. The GPU blades, acting as coprocessors for the CPU, are responsible for completing signal processing tasks such as data transposition, pulse compression, MTD, and constant false alarm rate (CFAR) detection for an entire CPI of data, and then sending the processed single-point report to the CPU. To shorten processing time and meet the requirements of a time-sensitive system, the computation cycle needs to be shortened to meet system time requirements. Therefore, to fully leverage the advantages of the GPU, a multi-stream processing architecture is required. Each stream independently completes the signal processing of an entire CPI of data and sends out the processing result; therefore, the processing process of each stream is completely identical. The CPU sequentially sends the data within each CPI to multiple streams for processing according to the receiving order. The multiple streams process in parallel, and the processed single-point report is sent to the CPU. The data input allocation is as follows: Figure 2 As shown. Because the amount of data within the CPI of each stream processing is not constant, and due to operating system scheduling and other jitter, the single point reports output by each stream are not output in the order of input. Therefore, it is necessary to synchronize the single point reports output by multiple streams to achieve on-demand reporting.

[0037] 2. The received beam data is sequentially stored in several buffers, numbered as follows: Once the buffer has finished receiving beam data, the number of streams processed is determined using the buffer's identifier. The modulo operation is performed; if the remainder is 0, the beam data in the corresponding buffer is sent to stream 1 for processing; if the remainder is 2, it is sent to stream 2, and so on, repeating this process to sequentially send the received beam data to the corresponding stream for processing. The input beam data includes a timestamp, which increments synchronously with the CPI and is unique within the signal processing system. After each stream completes processing, it combines its processing result with the corresponding timestamp to form a frame report, which is then stored in a shared memory queue shared by multiple streams. When writing the processing result to the shared memory queue, a mutex lock protection operation is required to ensure that the data written to the shared memory queue at any given time is the complete frame report of the current stream.

[0038] 3. In the data processing thread, the shared memory queue storing the results of multi-stream processing is checked in real time. If the shared memory queue is empty, the process continues to wait; otherwise, all processing results from each stream in the shared memory queue are stored into a circular queue. When storing processing results from the shared memory queue into the circular queue, a mutex lock is used to protect the read operations of the shared memory queue to prevent write operations from occurring during read operations, ensuring data consistency. Figure 3 As shown. Similarly, write operations to a circular queue also require mutex lock protection.

[0039] 4. Frame reports must be sent in ascending order of timestamp, and the timestamp difference between consecutive frame reports must be a fixed value. The circular queue status is checked in real-time. If the circular queue is not empty, the number of frame reports in the queue is checked. If there is only one frame report in the queue, frame report sending is initiated directly. If there are more than one frame report in the queue, the frame reports in the queue are sorted in ascending order of timestamp. After sorting, frame report sending begins. When sending a frame report, it is first determined whether the current sending state is the first sending since system startup. If it is the first sending, the current frame report is sent directly, and the timestamp in the current frame report is recorded as the sending timestamp. If it is not the first sending, frame reports are read sequentially from the circular queue, and the current timestamp is retrieved from the frame report. The current timestamp is compared with the sending timestamp. If it is less than or equal to the sending timestamp, the frame report is deleted from the circular queue; otherwise, no processing is performed. This process is repeated for all frame reports until the timestamps of all reports in the circular queue meet the requirements. Figure 4 As shown.

[0040] 5. Read out the remaining eligible frame reports in the circular queue in sequence, and record the timestamp of the currently read frame report. Use the timestamp of the current frame report as the current timestamp. Calculate the difference between the current timestamp and the sending timestamp, and set the difference against the timestamp difference threshold. Compare the differences; if the difference equals the timestamp difference threshold... If the frame is not reported, the current timestamp will be recorded as the transmission timestamp, and the timestamp error counter threshold will be set. Reset to zero. If the difference is not equal to the timestamp difference threshold. If the timestamp error counter is greater than or equal to the maximum threshold value, then increment the timestamp error counter by one. Add the sending timestamp At the same time, the timestamp error counter is reset to zero. Otherwise, no processing is performed, and frame report transmission continues, such as... Figure 5 As shown.

[0041] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0042] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is defined only by the appended claims.

Claims

1. A method for GPU multi-stream data synchronization using a dynamic circular queue, characterized in that, The method includes: Step 1: Construct a shared memory queue to receive processing results from multiple processing streams from the GPU; check in real time whether the shared memory queue is empty. If it is not empty, store all processing results in the shared memory queue into a circular queue. Step 2: Organize the data in the circular queue, and determine the method of sending it to the dynamic scheduling management module based on the number of frame reports in the circular queue; Step 3: In the dynamic scheduling management module, determine whether this is the first transmission after system startup; if so, directly send the current frame report and record the timestamp of the frame report as the transmission timestamp; otherwise, read the frame reports sequentially according to the order of the circular queue, extract the timestamp of the current frame report as the current timestamp, and if the current timestamp is less than or equal to the transmission timestamp, delete the frame report from the circular queue; traverse the circular queue until the current timestamp of all frame reports in the queue is greater than the transmission timestamp; Step 4: Read the remaining frame reports in the circular queue in sequence, record the timestamp of the current frame report being read as the current timestamp, and calculate the difference between the current timestamp and the sending timestamp; by comparing the timestamp difference with the timestamp difference threshold, construct a dynamic scheduling mechanism based on timestamp management to realize the output of frame reports on demand in the order of timestamps.

2. The method according to claim 1, characterized in that, Mutex locks are applied to read and write operations on the shared memory queue and to write operations on the circular queue to ensure data consistency.

3. The method according to claim 1, characterized in that, The method for determining the method of sending frames to the dynamic scheduling management module based on the number of frame reports in the circular queue is as follows: The number of frame reports in the circular queue is determined. If there is only one frame, it is directly sent to the dynamic scheduling management module. If there is more than one frame, the frame reports in the queue are sorted in ascending order of timestamp information attached to each frame report, and the sorted frame reports are sent to the dynamic scheduling management module.

4. The method according to claim 1, characterized in that, The process involves comparing the timestamp difference with a timestamp difference threshold to construct a dynamic scheduling mechanism based on timestamp management. This mechanism enables frame reports to be output on demand in timestamp order. Specifically: If the timestamp difference is equal to the preset timestamp difference threshold, then send the frame report, update the sending timestamp to the current timestamp, and clear the timestamp error counter. If the difference is not equal to the timestamp difference threshold, then increment the timestamp error counter by one; If the value of the timestamp error counter reaches the preset maximum error count threshold, the sent timestamp will be increased by the timestamp difference threshold, and the timestamp error counter will be cleared to zero. Repeat this step until the circular queue is empty.

5. The method according to claim 4, characterized in that, The preset timestamp difference threshold is 1.

6. The method according to claim 4, characterized in that, The preset maximum error count threshold is 4.

7. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the GPU multi-stream data synchronization method using a dynamic circular queue as described in any one of claims 1 to 6.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the GPU multi-stream data synchronization method using a dynamic circular queue as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the GPU multi-stream data synchronization method based on the dynamic circular queue as described in any one of claims 1 to 6 by executing the executable instructions.

Images