Thread communication method based on dynamic BP strategy

Abstract

The invention discloses a thread communication method based on a dynamic BP strategy, and the method comprises the steps: setting the data size for a consumer thread, enabling a producer thread and the consumer thread to carry out the communication between threads through an event notification method in a default manner, carrying out the event notification once when the producer thread generates one piece of data, and notifying a consumer to process the data, the consumer thread detects an event notification, triggers data processing, calculates a weight according to a business scene, judges whether to enter a BP state or not, sets the consumer to enter the BP state when the weight of the consumer thread is higher than a set data volume high water level, and sets the consumer to exit the BP state when the weight of the consumer thread is lower than a set data volume low water level. According to the method, the timeliness of event notification and the high efficiency of polling processing are both achieved, and CPU computing resources are reasonably allocated to cope with a complex inter-thread communication environment according to a dynamic adjustment thread communication method of the data size.

Description

Technical Field

[0001] The present invention relates to the field of multi-threading technology, and more particularly to a thread communication method based on a dynamic BP strategy. Background Art

[0002] Existing financial systems often employ a single approach to inter-thread communication, which can be broadly divided into two categories. The first uses event notifications for inter-thread communication. Each time a producer thread generates data, it issues an event notification, and the consumer thread triggers a data processing response based on the event notification. This approach suffers from the fact that each inter-thread event notification consumes a significant amount of time, reducing data processing efficiency. This is particularly true for large data volumes, leading to data backlogs and system lags. The second approach involves consumer threads using polling to check and process data generated by producer threads. This approach also suffers from the difficulty of establishing a reasonable polling interval. If the interval is too large, large bursts of data cannot be processed promptly, resulting in data backlogs and system lags. If the interval is too small, the CPU polls idle when data volumes are low, wasting computing resources and starving other consumers on the same thread of sufficient computing resources. Summary of the Invention

[0003] In view of the above problems, the present invention provides a thread communication method based on a dynamic BP strategy to solve the drawbacks of existing technical methods and resolve the contradiction between improving data processing speed and rationally allocating resources.

[0004] The present invention provides a thread communication method based on a dynamic BP strategy, comprising the following steps:

[0005] S1. Set the data volume high and low watermarks for the consumer thread;

[0006] S2. The producer thread and the consumer thread use the event notification method to communicate between threads by default;

[0007] S3. Every time the producer thread generates a piece of data, it issues an event notification to notify the consumer to process the data;

[0008] S4. The consumer thread detects the event notification, triggers data processing, calculates the weight according to the business scenario, and determines whether to enter the BP state;

[0009] S5. When the consumer thread weight is higher than the high watermark set in S1, the consumer is set to enter the BP state;

[0010] S6. When the consumer thread weight is lower than the low watermark set in S1, the consumer is set to exit the BP state.

[0011] Preferably, the high water mark is estimated according to the data volume during busy business hours.

[0012] Preferably, the low water mark is estimated according to the data volume when the business is not busy.

[0013] Preferably, the data volume high and low water levels are thresholds for determining whether a consumer enters or exits a BP state.

[0014] Preferably, the data in step S3 includes business instructions, management instructions, and business data.

[0015] Preferably, the weight calculation method includes calculation based on average data processing volume, calculation based on data peak value per second, and calculation based on remaining unprocessed data volume.

[0016] Preferably, the step S5 notifies the producer thread to stop generating event notifications to reduce thread synchronization consumption, and the consumer thread adopts a polling method to quickly process data and synchronously accumulate weights.

[0017] Preferably, the step S6 notifies the producer thread to resume using the event notification inter-thread communication method.

[0018] The beneficial effects of the present invention are as follows: the present invention combines the timeliness of event notification and the high efficiency of polling processing, can dynamically adjust the thread communication method according to the size of data, reasonably allocate CPU computing resources, and cope with complex inter-thread communication environments.

[0019] When the data volume is low, the default method of event notification is used between threads. The data generated by the producer thread is promptly aroused by the consumer thread through event notification, ensuring the timeliness of data processing while not occupying too much processing time of the consumer thread, ensuring that the processing capabilities of other consumers on the same thread are not affected. When the data volume is high, the communication method between threads is adjusted, the producer thread no longer generates event notifications, and all resources are used for data processing. The consumer thread no longer checks event notifications and uses polling method to process data at high speed, greatly improving the system throughput.

[0020] The method designed by the present invention can solve the problem of a system that needs to cope with a complex thread communication environment and needs to balance the timeliness of constant data processing and the efficiency of large-scale data processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a flow chart of the thread communication method of the dynamic BP strategy of the present invention. Specific implementation methods Specific embodiments

[0023] A thread communication method based on a dynamic BP strategy comprises the following steps:

[0024] S1. Set the data volume high and low watermarks for the consumer thread;

[0025] S2. The producer thread and the consumer thread use the event notification method to communicate between threads by default;

[0026] S3. Every time the producer thread generates a piece of data, it issues an event notification to notify the consumer to process the data;

[0027] S4. The consumer thread detects the event notification, triggers data processing, calculates the weight according to the business scenario, and determines whether to enter the BP state;

[0028] S5. When the consumer thread weight is higher than the high watermark set in S1, the consumer is set to enter the BP state;

[0029] S6. When the consumer thread weight is lower than the low watermark set in S1, the consumer is set to exit the BP state.

[0030] The high water mark is estimated based on the data volume during peak business hours.

[0031] The low water mark is estimated based on the data volume when the business is not busy.

[0032] The data volume high and low water levels are thresholds for determining whether a consumer enters or exits the BP state.

[0033] The data in step S3 includes business instructions, management instructions, and business data.

[0034] The weight calculation method includes calculation based on average data processing volume, calculation based on peak data volume per second, and calculation based on remaining unprocessed data volume.

[0035] The step S5 notifies the producer thread to stop generating event notifications to reduce thread synchronization consumption, and the consumer thread adopts a polling method to quickly process data and synchronously accumulate weights.

[0036] The step S6 notifies the producer thread to resume using the event notification inter-thread communication method. The present invention combines the timeliness of event notification with the high efficiency of polling processing, can dynamically adjust the thread communication method according to the amount of data, reasonably allocate CPU computing resources, and cope with complex inter-thread communication environments.

[0037] The following further describes a thread communication method based on a dynamic BP strategy of the present invention.

[0038] A thread communication method based on a dynamic BusyPolling (busy polling state hereinafter referred to as BP) strategy includes the following steps:

[0039] S1: When the financial system starts, threads are classified into producer threads and consumer threads based on their different functions. Producer threads are data production threads, such as futures order production threads and futures market production threads; consumer threads are data processing threads, such as futures order processing threads and futures market processing threads. Data volume high and low watermarks (i.e., judgment thresholds) are set for each consumer thread. The high watermark is used for entering the BP state judgment, and the low watermark is used for exiting the BP state judgment.

[0040] S2: By default, the producer thread and the consumer thread use the event notification method for inter-thread communication;

[0041] S3: Every time a producer thread generates data that needs to be synchronized between threads (including but not limited to business instructions, management instructions, business data such as orders, market information, etc.) and puts it into the data queue, an event notification is issued to notify the consumer to process the data;

[0042] S4: The consumer thread detects the event notification, triggers data processing, takes data from the data queue, calculates the weight according to the business scenario (calculation methods include but are not limited to calculation based on average data processing volume, calculation based on peak data per second, calculation based on the remaining unprocessed data volume, etc.), and determines whether to enter the BP state;

[0043] S5: When the consumer thread weight is higher than the high watermark set in S1, the producer and consumer are set to enter the BP state. The producer thread stops event notification in the BP state (event notification between threads requires kernel synchronization state writing, which is time-consuming), which greatly improves the efficiency of business data production and makes the producer thread close to the processing capacity of a full-load single thread. At the same time, the consumer thread no longer checks event notifications, and uses a polling method to process data in the data list. All computing resources of the thread are used for data processing. Since the time for checking event notifications is saved, the business data processing efficiency is greatly improved, and the consumer thread is close to the processing capacity of a full-load single thread;

[0044] S6: When the consumer thread weight falls below the low watermark set in S1, the producer and consumer exit the BP state. The producer thread resumes using event notifications for inter-thread communication. The consumer thread stops polling the data queue and resumes waiting for event notifications to process data. When data is low, using event notifications ensures timely data processing while freeing up computing resources for other operations when data is unavailable.

[0045] Taking the financial futures trading order processing system as an example

[0046] S1: When the system starts, the high watermark for the order processing thread (consumer thread) is set to 10,000 orders per second and the low watermark is set to 1,000 orders per second.

[0047] S2: The order production thread (producer thread) and the order processing thread (consumer thread) use event notification by default (the producer calls the write method to write fd, and the consumer thread epoll_wait checks the fd write status and obtains event notification) to communicate between threads.

[0048] S3: The futures trading order production thread generates an event notification each time it places an order into the order queue. The order processing thread detects the event notification and retrieves the order from the order queue for processing.

[0049] S4: The weight of the order processing thread increases by 1 each time it processes an order. If 20,000 orders are processed in 1 second, the accumulated weight is 20,000.

[0050] S5: If the order processing thread accumulates 20,000 orders per second, which is higher than the high watermark of 10,000 orders per second set in S1, the order production thread and the order processing thread are set to enter the BP state. The order production thread stops event notification in the BP state and no longer calls the write method to write fd (time-consuming). It only generates orders and puts them into the order queue, greatly improving the efficiency of generating orders. The order processing thread no longer calls the epoll_wait method (time-consuming) to check event notifications, but directly uses the polling method to take orders out of the order queue for processing. Since the epoll_wait call time is saved, the business data processing efficiency is greatly improved;

[0051] S6: After a period of efficient operation, the orders generated by the order production thread are processed by the order processing thread. The cumulative number of orders processed by the order processing thread is 500 per second, which is lower than the low water mark of 1,000 per second set in S1. The order production thread and the order processing thread exit the BP state, and the order creation thread resumes the event notification method. Each time an order is generated, it is put into the order list, calls the write method to write fd, and notifies the order processing thread to process the order; the order processing thread no longer polls to read the order data in the order list, and resumes calling the epoll_wait method to check event notifications, and obtains orders according to the notification for processing.

[0052] The present invention combines the timeliness of event notification with the high efficiency of polling processing, can dynamically adjust the thread communication method according to the size of data, reasonably allocate CPU computing resources, and cope with complex inter-thread communication environments.

[0053] When data volumes are low, the default inter-thread communication method is event notification. Data generated by the producer thread is promptly processed by the consumer thread through event notifications. This ensures timely data processing while minimizing the processing time of the consumer thread and protecting the processing capabilities of other consumers on the same thread. When data volumes are high, the inter-thread communication method is adjusted. The producer thread no longer generates event notifications, dedicating all resources to data processing. Consumer threads no longer check for event notifications and instead use polling to process data at high speed, significantly improving system throughput.

[0054] The method designed by the present invention can solve the problem of a system that needs to cope with a complex thread communication environment and needs to balance the timeliness of constant data processing and the efficiency of large-scale data processing.

[0055] The above is only a preferred specific implementation method of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with this technical field, within the technical scope disclosed by the present invention, who makes equivalent replacements or changes based on the technical solution and inventive concept of the present invention, should be covered by the scope of protection of the present invention.

Claims

1. A thread communication method based on dynamic BP strategy, characterized in that: The following steps are involved: S1. Set the high and low watermarks of data volume for the consumer thread; S2. The producer thread and the consumer thread use the event notification method to communicate between threads by default; S3: Every time a piece of data is generated by the producer thread, an event notification is made to notify the consumer to process the data; S4, the consumer thread detects the event notification, triggers data processing, calculates the weight according to the business scenario, and determines whether to enter the BP state; S5. When the consumer thread weight is higher than the high water mark set in S1, the consumer is set to enter the BP state; S6. When the consumer thread weight is lower than the low water mark set in S1, the consumer is set to exit the BP state.

2. According to the thread communication method based on dynamic BP strategy in claim 1, it is characterized in that: The high water mark is estimated according to the data volume during busy business hours.

3. According to the thread communication method based on dynamic BP strategy in claim 1, it is characterized in that: The low water mark is estimated according to the data volume when the business is not busy.

4. According to the thread communication method based on dynamic BP strategy in claim 1, it is characterized in that: The data volume high and low water levels are thresholds for determining whether a consumer enters or exits the BP state.

5. The thread communication method based on dynamic BP strategy according to claim 1, characterized in that: The data in step S3 includes business instructions, management instructions, and business data.

6. The thread communication method based on dynamic BP strategy according to claim 1, characterized in that: The weight calculation method includes calculation based on average data processing volume, calculation based on data peak value per second, and calculation based on remaining unprocessed data volume.

7. The thread communication method based on dynamic BP strategy according to claim 1, characterized in that: The step S5 notifies the producer thread to stop generating event notifications to reduce thread synchronization consumption, and the consumer thread adopts a polling method to quickly process data and synchronously accumulate weights.

8. The thread communication method based on dynamic BP strategy according to claim 1, characterized in that: The step S6 notifies the producer thread to resume using the event notification inter-thread communication method.

Images