A dynamic adjustment method, device and electronic equipment of a task queue

Abstract

This application discloses a method, apparatus, and electronic device for dynamically adjusting a task queue. The method includes: generating tasks based on task configuration information and storing the tasks in a pre-execution task queue; storing tasks in the pre-execution task queue that meet the execution conditions into a task execution queue; determining a prediction coefficient for the task based on the task's actual execution time in the previous run and its historical average execution time, and determining the estimated execution time of the task based on the historical average execution time and the prediction coefficient; determining the number of executable tasks based on the server's real-time resource load, the task's historical average resource load, and the number of tasks currently being executed by the server, and selecting tasks to be executed from the task execution queue; if, based on the historical average resource load and real-time resource load of the tasks to be executed, it is determined that the resources do not meet the concurrency requirements, then the tasks to be executed are scheduled according to the estimated execution time. The above technical solution improves task execution efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, apparatus, and electronic device for dynamically adjusting a task queue. Background Technology

[0002] In the operation and management of smart transportation hubs, the task scheduling system, as the central hub for core business functions such as station equipment control, passenger flow management, and emergency response, faces the severe challenge of concurrent execution of multiple types of tasks. Traditional static scheduling mechanisms typically employ a single priority queue or a fixed-time polling strategy, which struggles to effectively handle mixed load scenarios that include time-triggered tasks (such as daily scheduled passenger flow statistics reports and equipment inspection plans) and condition-triggered tasks (such as emergency response and dynamic resource allocation instructions). Especially in high-concurrency environments such as subway and high-speed rail stations, time-triggered tasks need to strictly adhere to preset execution sequences to ensure business compliance, while condition-triggered tasks require real-time responses to environmental changes to ensure operational safety. These two types of tasks are highly prone to execution conflicts when competing for resources. Therefore, effective task scheduling is crucial. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for dynamically adjusting a task queue to improve task execution efficiency.

[0004] In a first aspect, embodiments of this application provide a method for dynamically adjusting a task queue, comprising: Tasks are generated based on task configuration information and stored in a pre-execution task queue; The tasks in the pre-execution task queue are monitored in real time, and tasks that meet the execution conditions are stored in the task execution queue. Based on the actual execution time of the task in the previous execution and the historical average execution time, the prediction coefficient of the task is determined, and based on the historical average execution time and the prediction coefficient, the estimated execution time of the task is determined. Based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, the number of executable tasks M is determined, and M tasks to be executed are selected from the task execution queue. Based on the historical average resource load of the M tasks to be executed and the real-time resource load, determine whether the resources meet the concurrency requirements of the M tasks to be executed. If the resources do not meet the concurrency requirements, the M tasks to be executed will be scheduled according to the corresponding estimated execution time.

[0005] Secondly, embodiments of this application also provide a dynamic adjustment device for a task queue, comprising: The pre-execution task queue module generates tasks based on task configuration information and stores the tasks in the pre-execution task queue; The task execution queue module is used to monitor the tasks in the pre-execution task queue in real time and store the tasks that meet the execution conditions into the task execution queue. The estimated execution time module is used to determine the estimated coefficient of a task based on the actual execution time of the task in the previous execution and the historical average execution time, and to determine the estimated execution time of the task based on the historical average execution time and the estimated coefficient. The task-to-be-executed module is used to determine the number of executable tasks M based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, and to select M tasks to be executed from the task execution queue. The concurrency requirement determination module is used to determine whether the resources meet the concurrency requirements of the M tasks to be executed based on the historical average resource load of the M tasks to be executed and the real-time resource load. The task scheduling module is used to schedule the M tasks to be executed according to the estimated execution time if the resources do not meet the concurrency requirements.

[0006] Thirdly, embodiments of this application also provide an electronic device, which includes: One or more processors; Storage device for storing one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement any of the dynamic adjustment methods for task queues provided in the embodiments of this application.

[0007] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements any of the dynamic adjustment methods for task queues provided in embodiments of this application.

[0008] This application stores tasks that meet the execution conditions in the pre-execution task queue into the task execution queue. For tasks in the task execution queue, it dynamically calculates an estimation coefficient based on the previous actual execution time and the historical average execution time, and calculates the estimated execution time of the task based on the historical average execution time and the estimation coefficient, which serves as the core basis for task priority ranking and execution order scheduling. Furthermore, it collects the real-time resource load of the server and the historical average resource load of each task in the task execution queue, and, combined with the number of currently running tasks, accurately calculates the number of executable tasks M, and selects M tasks to be executed from the task execution queue. It combines the real-time resource load of the server with the historical average resource load of the M tasks to be executed to determine whether the resources meet the concurrency requirements. If the concurrency requirements are not met, a portion of the M tasks to be executed are selected for concurrent execution based on the estimated execution time, maximizing resource utilization while ensuring server stability. If the concurrency requirements are met, the M tasks to be executed are executed concurrently, ensuring that the system is not overloaded and improving overall execution efficiency through task batch processing.

[0009] Therefore, the technical solution of this application solves the problem and achieves the desired effect. Attached Figure Description

[0010] Figure 1a This is a flowchart of a method for dynamically adjusting a task queue according to Embodiment 1 of this application; Figure 1b This is a schematic diagram of a pre-execution task queue structure provided in Embodiment 1 of this application; Figure 1c This is a schematic diagram illustrating the principle of determining a task execution queue according to Embodiment 1 of this application; Figure 2 This is a flowchart of another method for dynamically adjusting a task queue according to Embodiment 2 of this application; Figure 3 This is a schematic diagram of the structure of a dynamic adjustment device for a task queue according to Embodiment 3 of this application; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the dynamic adjustment method of the task queue according to the embodiments of this application. Detailed Implementation

[0011] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0012] It should be noted that the terms "first" and "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0013] Example 1 Figure 1a This is a flowchart of a dynamic adjustment method for a task queue according to Embodiment 1 of this application. This embodiment is applicable to the scheduling of tasks in intelligent station operation management software platforms such as subways. It can be executed by a dynamic adjustment device for the task queue, which can be implemented in hardware and / or software and can be configured in a computer device. Figure 1a As shown, the method includes: S101. Generate a task based on the task configuration information and store the task in the pre-execution task queue; S102. Monitor the tasks in the pre-execution task queue in real time, and store the tasks that meet the execution conditions into the task execution queue. S103. Based on the actual execution time of the task in the previous execution and the historical average execution time, determine the prediction coefficient of the task, and based on the historical average execution time and the prediction coefficient, determine the estimated execution time of the task. S104. Based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, determine the number of executable tasks M, and select M tasks to be executed from the task execution queue. S105. Based on the historical average resource load of the M tasks to be executed and the real-time resource load, determine whether the resources meet the concurrency requirements of the M tasks to be executed. S106. If the resources do not meet the concurrency requirements, the M tasks to be executed are scheduled according to the corresponding estimated execution time.

[0014] The tasks in the pre-execution task queue are generated based on pre-configured task parameters. Users can configure (create, modify, and delete) tasks and set task parameters and other configuration information in the smart station operation management software platform. Task parameters include attributes such as task type, effective execution time range, loop mode, preconditions, task weight, trigger mode, and special task identifier. Task types include single tasks, recurring tasks, calendar tasks, and conditional tasks; the effective execution time range sets the maximum time span for task execution, such as January 2025 to December 2025; the loop mode is a unique attribute for recurring tasks, used to set the time interval for task looping (e.g., monthly, weekly, hourly); preconditions are unique attributes for conditional tasks, including execution count limits and conditional dependencies; task weight is a pre-set empirical value during task creation, with higher values ​​indicating higher weight, used for initial sorting of the task queue; the trigger mode supports three methods: time-triggered, manual-triggered, and event-triggered; event-triggered means that task execution is automatically triggered when external events (such as data readiness, API callbacks) or system states meet preset conditions; special task identifiers are used to mark special task attributes. The system generates tasks (which can be called task instances) to be executed the next day at a fixed time every day (e.g., 23:30) based on pre-set task parameters, and stores the generated tasks in the pre-execution task queue.

[0015] The task execution queue stores tasks to be executed within the current time window, with a precision down to the second level, such as 1 second. For conditional tasks in the pre-execution queue, preconditions such as execution count limits and dependencies are monitored in real time to determine if the task meets the execution conditions. Conditional tasks that meet the conditions are then moved to the task execution queue. For time-triggered tasks such as single-task tasks, recurring tasks, and calendar tasks in the pre-execution queue, execution conditions are monitored in real time based on the trigger timing. Time-triggered tasks that meet the execution conditions are written to the task execution queue. It should be noted that if any task includes both trigger conditions and trigger timing, then that task is a conditional task.

[0016] During task execution, timers or system logs can be used to record the actual running time from start to finish. For example, a timing thread can be started in the program, and when the task is completed, the total time is recorded and the data is stored in the task information table. Multiple execution records of the same task (e.g., the last 10 times) can be stored and managed, and the average historical execution time of the task can be calculated to obtain the historical average execution time. For example, if a task was executed 5 times, taking 28 minutes, 32 minutes, 30 minutes, 29 minutes, and 31 minutes respectively, the historical average execution time of the task is: (28 + 32 + 30 + 29 + 31) ÷ 5 = 30 minutes.

[0017] For any given task, a prediction coefficient can be determined based on its previous actual execution time and historical average execution time. This coefficient reflects the trend in task execution time. The estimated execution time is then calculated using the historical average execution time and the prediction coefficient, making the estimated execution time closer to the actual execution situation and improving its accuracy. The estimated execution time serves as a crucial basis for task scheduling, determining task priority and execution order, helping to optimize resource allocation and avoid resource waste and task execution delays. It should be noted that during the task creation phase, an initial estimated execution time can be set for the task based on manual experience or by referring to historical data from similar tasks (i.e., initializing the task's estimated execution time). For example, based on past project experience, a 30-minute estimated execution time can be set for a data cleaning task.

[0018] Furthermore, resource usage data for servers and tasks can be collected in real time via system APIs (such as resource query interfaces provided by the operating system) or monitoring tools, and timestamps can be recorded to obtain the real-time resource load of the server and the historical resource load of tasks during historical execution. The historical average resource load of the same task can be obtained by averaging multiple historical resource loads. Resource usage data may include CPU utilization, memory usage, etc. The server's load type (low load, normal load, or high load) is determined based on its real-time resource load. Different task scheduling strategies can be adopted for different load types to determine the number of executable tasks M, and select M tasks to be executed from the task execution queue, where M is a positive integer. Different load types correspond to different concurrent task counts; low load corresponds to a higher concurrent task count than high load. Alternatively, different load types may have different task priorities: under low load, tasks with higher historical average resource load are prioritized; under high load, tasks with lower historical average resource load are prioritized. By accurately calculating the number of executable tasks M based on the server's real-time resource load, the historical average resource load of each task in the task execution queue, and the number of tasks currently being executed by the server, and selecting M tasks to be executed from the task execution queue, the system achieves precise matching between the tasks to be executed and the server's current resource load status and task priority requirements, thereby realizing intelligent task selection and improving the accuracy of the tasks to be executed.

[0019] Based on the server's real-time resource load, calculate the remaining available resources. Based on the historical average resource load of the M pending tasks, calculate the total resource load required by each task. Compare the remaining available resource load with the total resource load. If the remaining available resource load is less than the total resource load, the resources cannot meet the concurrent requirements of the M pending tasks. In this case, dynamically schedule the M pending tasks based on their estimated execution time, selecting a portion of them for concurrent execution to maximize resource utilization while ensuring stable server operation. If the remaining available resource load is equal to or greater than the total resource load, the resources meet the concurrency requirements, and the M pending tasks are executed concurrently, improving task processing efficiency while ensuring server load safety.

[0020] The technical solution of this embodiment stores tasks that meet the execution conditions in the pre-execution task queue into the task execution queue. For tasks in the task execution queue, a prediction coefficient is dynamically calculated based on the previous actual execution time and the historical average execution time. The estimated execution time of the task is then calculated based on the historical average execution time and the prediction coefficient, serving as the core basis for task priority ranking and execution order scheduling. Furthermore, the real-time resource load of the server and the historical average resource load of each task in the task execution queue are collected. Combined with the number of currently running tasks, the number of executable tasks M is accurately calculated, and M tasks are selected from the task execution queue to be executed. The real-time resource load of the server and the historical average resource load of the M tasks to be executed are used to determine whether the resources meet the concurrency requirements. If the concurrency requirements are not met, a portion of the M tasks to be executed are selected for concurrent execution based on the estimated execution time, maximizing resource utilization while ensuring server stability. If the concurrency requirements are met, the M tasks to be executed are executed concurrently, ensuring that the system is not overloaded and improving overall execution efficiency through task batch processing.

[0021] In one optional implementation, the pre-execution task queue includes a first conditional sub-queue and a first time-order sub-queue; the first conditional sub-queue is located at the head of the pre-execution task queue, and the first time-order sub-queue is located at the tail of the queue; the first time-order sub-queue may include a time-conflict sub-queue, each of the time-conflict sub-queues including multiple time-ordered tasks with the same timestamp, and the multiple time-ordered tasks are sorted according to task weight; the task execution queue includes a second conditional sub-queue and a second time-order sub-queue; the second conditional sub-queue is located at the head of the task execution queue, and the second time-order sub-queue is located at the tail of the queue, the time-ordered tasks in the time-conflict sub-queues are sorted according to timestamp priority, and those with the same timestamp are sorted according to task weight priority.

[0022] refer to Figure 1bThe pre-execution task queue includes a first conditional sub-queue and a first time-order sub-queue. The first conditional sub-queue is at the head of the queue, and the first time-order sub-queue is at the tail, meaning the first conditional sub-queue precedes the first time-order sub-queue. The first time-order sub-queue may include time-triggered tasks (referred to as time tasks) and conflict sub-queues. Each conflict sub-queue may include at least two time tasks, and multiple time tasks in a single conflict sub-queue have the same timestamp. Multiple time tasks in a conflict sub-queue can be sorted according to task weight, with higher weight tasks listed first. For example, at a fixed time each day (e.g., 23:30), tasks to be executed the next day are generated based on pre-set task parameters. Conditional tasks are written to the first conditional sub-queue in descending order of execution time; time tasks are written to the first time sub-queue in descending order of execution time. When multiple time tasks are associated with the same timestamp, the multiple time tasks are stored in the same conflict sub-queue and sorted by task weight. This structural design prioritizes conditional tasks over time tasks and allows for real-time monitoring of whether multiple time tasks in a single conflict sub-queue meet the execution conditions, thereby improving the monitoring efficiency of the first time-order sub-queue.

[0023] Time-based tasks can include single tasks, recurring tasks, and calendar tasks. For single tasks, it can be determined whether the execution time set for the single task is on the next day. If it falls within the time range, the single task is written to the first time-sequence subqueue. For recurring tasks, task instances for all execution times (such as 0:00, 2:00, 4:00, etc.) on the next day can be generated according to the task's recurrence rules and written to the first time-sequence subqueue. For calendar tasks, based on the date type (such as "weekdays + non-holidays") and time period (such as "9:00-12:00") in the calendar, task instances that meet the date / time settings for the next day are generated. If the time period is multiple (such as "morning + afternoon" with a task executed every 5 minutes), it can be split into independent task instances and included in the first time-sequence subqueue.

[0024] A single task is the smallest unit of task executed independently at once. A single task requires the following key parameters: execution date, execution time, task weight, trigger method (manual / scheduled / event), and whether it is a special task identifier; and the execution time of the single task, which can be accurate to the second, such as executing at 12:30:00 on a specific day, month, and year. A recurring task is a task that automatically repeats itself within a certain time period within its effective execution time range. It is usually based on a time dimension (year / month / week / day / hour / minute / second) or triggered by specific events, forming diverse scheduling strategies through combinations of recurring methods. A recurring task requires the following key parameters: effective execution time range (expressed in years / month / week / day / hour / minute / second), recurring method (monthly, weekly, daily, hourly), recurring time point type (single recurrence / multiple recurrences), calendar-related parameters (weekdays, public holidays, etc.), trigger method (time / preceding task / event), and whether it is a special task identifier. Calendar tasks are scheduled tasks triggered based on custom date types and time periods. Execution rules are defined by associating date types (weekdays, holidays, special event days) with time period types (e.g., morning rush hour 9:00-10:00, night shift 22:00-6:00), and multiple time periods can be overlapped. The core of calendar tasks is the flexible combination of date types (static – national legal date types / dynamic – user-defined date types) + time periods (single / multiple segments) + trigger rules to adapt to complex business scenarios. Custom calendars allow for the definition of various date types to determine the execution date of calendar tasks based on different needs and scenarios.

[0025] Tasks with the same execution time in the first time-order queue are detected, and conflict sub-queues are generated according to their execution time. Multiple time-order tasks with the same execution time are grouped into one time-conflict sub-queue. The first time-order sub-queue may contain multiple time-conflict sub-queues, and these sub-queues and individual time tasks are arranged in the order of their execution time. Multiple time tasks in a single time-conflict sub-queue can be sorted in descending order of task weight. If a complex task includes multiple sub-tasks, and any sub-task is a conditional task, then the complex task is treated as a conditional task and stored in the first conditional sub-queue. For example, a complex task that includes both time-order and conditional sub-tasks is placed in the first conditional sub-queue, not the first time-order sub-queue. For instance, the task "Flag-raising ceremony at 9:00 AM on Monday under clear skies" is stored in the first conditional sub-queue.

[0026] The conditional task requires setting the following key parameters: prerequisites (number of executions limit, prerequisite dependencies), restart conditions, triggering method, and whether it is a special task identifier. The number of executions limit is used to set the maximum number of times the task can be executed (e.g., "15 times per month"). After reaching the limit, the task will automatically go into hibernation until the restart conditions are met (e.g., the count is reset on the 1st of the following month). Prerequisite dependencies require all prerequisite tasks to be completed successfully. If a prerequisite task is delayed, the subsequent task will start in sequence. If it fails, manual intervention is required to confirm whether to continue. The restart condition is a unique attribute when the number of executions limit is used as a prerequisite. It refers to resetting the count and waking up the task at a specific time (e.g., when the cycle switches) after the maximum number of executions is reached.

[0027] refer to Figure 1c The task execution queue includes a second conditional subqueue and a second time-order subqueue. The second conditional subqueue is at the head of the queue, and the second time-order subqueue is at the tail. This means the second conditional subqueue precedes the second time-order subqueue, giving conditional tasks higher priority than time-order tasks. Specifically, it monitors whether conditional tasks in the first conditional subqueue meet their execution conditions. If so, the conditional task is placed in the second conditional subqueue. It also monitors whether time-order tasks in the first time-order subqueue have reached their execution time. If so, the time-order task is stored in the second time-order subqueue. If multiple time-conflict subqueues reach their execution time, they are sorted according to their weights, with the highest weights placed first, and then written into the second time-order subqueue. It's important to note that the first conditional subqueue has higher priority than the first time-order subqueue. The execution conditions of time-order tasks in the first time-order subqueue are only monitored after all conditional tasks in the first conditional subqueue are monitored in real-time, thus prioritizing conditional tasks over time-order tasks. After the conditional task monitoring is completed, the time tasks are processed according to the timestamp and weight rules. This not only ensures a rapid response to urgent conditional tasks, but also resolves the execution order conflicts of batch time tasks through the weight sorting mechanism of the conflict sub-queue, realizing the coordinated scheduling of priority tasks and periodic tasks.

[0028] In one optional implementation, the method further includes: in response to a special task, determining whether the requirements of the special task are met based on the real-time resource load of the server and the historical average resource load of the special task; if the requirements of the special task are met, then executing the special task; if the requirements of the special task are not met, then terminating the currently executing task and executing the special task.

[0029] If a task with a special task identifier is detected, the system immediately identifies it as a high-priority special task, extracts multiple historical resource loads of the feature task, calculates the average historical resource load of the feature task, and determines the remaining available resources of the server based on the server's real-time resource load. If the remaining available resources are greater than the historical average resource load of the special task, the special task is executed immediately, and M pending tasks are concurrently scheduled, i.e., the special task and task scheduling process are executed concurrently. If the remaining available resources are less than or equal to the historical average resource load of the special task, the currently executing task is discarded to release server resources, and the special task is executed until it is completed or terminated abnormally. Then, the scheduling and execution process of subsequent tasks is resumed according to the task execution queue. When the remaining available resources are less than or equal to the historical average resource load of the special task, not only is the currently executing task discarded, but the updates of the pre-execution task queue and the task execution queue are also suspended. Taking a fire at a station as an example, the fire-fighting task is a special task and is executed with priority to ensure the safety of the station.

[0030] Example 2 Figure 2 This is a flowchart of another method for dynamically adjusting a task queue according to Embodiment 2 of this application. The technical solution of this embodiment is further refined based on the above technical solution. See also Figure 2 The method for dynamically adjusting a task queue, as shown, includes: S201. Generate a task based on the task configuration information and store the task in the pre-execution task queue; S202. Monitor the tasks in the pre-execution task queue in real time, and store the tasks that meet the execution conditions into the task execution queue. S203. Based on the actual execution time of the task in the previous execution and the historical average execution time, determine the prediction coefficient of the task, and based on the historical average execution time and the prediction coefficient, determine the estimated execution time of the task. In one optional implementation, a predicted coefficient for the task is determined based on the task's actual execution time in the previous run and its historical average execution time. The predicted execution time of the task is then determined based on the historical average execution time and the predicted coefficient, comprising: subtracting the historical average execution time from the task's actual execution time in the previous run to obtain a duration difference; dividing the duration difference by the previous actual execution time to obtain the predicted coefficient for the task; using the sum of the predicted coefficient and the base coefficient as the task's current coefficient; and multiplying the task's historical average execution time by the task's current coefficient to obtain the task's predicted execution time.

[0031] The base coefficient is preset, for example, to 1. For any task in the task execution queue, the task's duration difference is obtained by subtracting its historical average execution time from its previous actual execution time; this duration difference is then divided by its previous actual execution time to obtain the task's estimated coefficient; the sum of the estimated coefficient and the base coefficient is used as the task's current coefficient; finally, the estimated execution time is obtained by multiplying the task's historical average execution time by the current coefficient. In other words, the estimated execution time of a task is calculated as follows: Prediction coefficient = (last actual execution time - historical average execution time) / last actual execution time; Estimated execution time = historical average execution time × (1 + estimation coefficient).

[0032] By calculating a prediction coefficient based on the difference between the task's actual execution time in the previous run and its historical average execution time, the prediction coefficient can automatically track the latest trend in task execution time. Multiplying the historical average execution time by the current coefficient preserves the task's current long-term execution trend while effectively eliminating prediction bias caused by single-run anomalies through coefficient adjustment. Therefore, the method for calculating predicted execution time combines the advantages of historical experience benchmarks and real-time dynamic correction, providing a more reliable basis for task prioritization and resource allocation.

[0033] S204. Determine the current load type based on the server's real-time resource load, and determine the current task concurrency N using the current coefficient corresponding to the current load type and the basic task concurrency L0. Here, the basic task concurrency L0 is a preset empirical value, and both L0 and N are natural numbers. For example, the server's real-time resource load is compared with preset first and second load thresholds. The first load threshold is lower than the second load threshold. If the real-time resource load is lower than the first load threshold (e.g., real-time CPU utilization is lower than 30%), the current load type is low load. If the real-time resource load is higher than the second load threshold (e.g., real-time CPU utilization is higher than 80%), the current load type is high load. If the real-time resource load is greater than the first load threshold but less than the second load threshold, the current load type is normal load. Based on the correlation between candidate load types and candidate coefficients, the current coefficient is determined according to the current load type. The current coefficient is multiplied by the basic task concurrency L0 to obtain the current task concurrency N. For example, if the current load type is low load, the current coefficient is K1; if the current load type is high load, the current coefficient is K2. K1 is greater than 1, K2 is less than 1, and both K1 and K2 are negatively correlated with the real-time resource load of the server. That is, the higher the real-time resource load, the smaller the current coefficient. If the current load type is normal load, the current coefficient is 1. When a low load state is detected, a coefficient K1 greater than 1 is used to amplify the concurrency of basic tasks, thereby fully releasing idle resources to accelerate task processing. In high load scenarios, a coefficient K2 less than 1 is used to compress the concurrency of basic tasks, effectively curbing the risk of overload and ensuring system stability.

[0034] S205. Subtract the number of tasks N0 that the server is currently executing from the current number of concurrent tasks N to obtain the number of executable tasks M; S206. Based on the current load type and the historical average resource load of the task, select M tasks to be executed from the task execution queue; S207. Based on the historical average resource load of the M tasks to be executed and the real-time resource load, determine whether the resources meet the concurrency requirements of the M tasks to be executed. S208. If the resources do not meet the concurrency requirements, the M tasks to be executed are scheduled according to the corresponding estimated execution time.

[0035] Subtracting the number of tasks N0 currently being executed by the server from the current number of concurrent tasks N, we obtain the number of executable tasks M. A dynamic scheduling strategy is determined based on the current load type, and this strategy is applied to select M tasks from the task execution queue based on the historical average resource load of each task. By combining different dynamic scheduling strategies with the current load type, the selection of tasks to be executed is matched to the current load type.

[0036] In one optional implementation, M tasks are selected from the task execution queue based on the current load type and the historical average resource load of the tasks, including: if the current load type is low load, then tasks with higher historical average resource utilization are selected first; if the current load type is high load, then tasks with lower historical average resource utilization are selected first; if the current load type is normal load, then tasks are selected according to their order in the task execution queue; if the historical average resource utilization of multiple tasks is close, then the task with the shorter estimated execution time is selected first; if the historical average resource utilization and the estimated execution time of multiple tasks are close, then the task with the earlier configuration time is selected first.

[0037] If the server is under low load, tasks with higher historical average resource utilization are prioritized from the task execution queue, resulting in M ​​tasks to be executed, thus making full use of idle resources. If the server is under high load, tasks with lower historical average resource utilization are prioritized from the task execution queue to avoid server overload and maintain server stability. If the historical average resource utilization of multiple tasks is similar, the estimated execution time of different tasks is further compared, and the task with the shorter estimated execution time is prioritized to shorten the resource occupation cycle. If the historical average resource utilization and estimated execution time of multiple tasks are similar, the configuration time of multiple tasks in the smart station operation management software platform is compared, and the task with the earlier configuration time is prioritized. By combining multiple factors such as the historical average resource utilization, estimated execution time, and configuration time, tasks to be executed are dynamically selected, achieving dynamic and orderly scheduling of tasks under complex conditions. If the server load is normal, tasks are selected according to their sorting order in the task execution queue. When the task execution queue includes a second conditional subqueue and a second time-sequence subqueue, with the second conditional subqueue at the head and the second time-sequence subqueue at the tail, tasks are selected from the second conditional subqueue first. After the second conditional subqueue is cleared, tasks are then selected from the second time-sequence subqueue. This dynamic scheduling capability is particularly important for intelligent station scenarios. When conditional tasks (such as passenger flow warnings or equipment malfunctions) arrive in the conditional subqueue, they are executed first to ensure station operational safety; while time-triggered tasks (such as scheduled report generation or equipment inspection) are executed in an orderly manner after the conditional tasks are executed, avoiding interference with conditional tasks that have high real-time requirements.

[0038] The technical solution in this embodiment calculates a prediction coefficient based on the difference between the actual execution time of a task in the previous instance and the historical average execution time, constructing a real-time feedback mechanism to enable the predicted execution time to automatically track the latest trend of task execution time changes. By multiplying the historical average execution time by the current coefficient, both long-term execution patterns are preserved, and prediction deviations caused by single execution anomalies are eliminated. Based on this, the concurrency strategy is dynamically adjusted according to the server's real-time resource load: under low load, coefficient K1 is used to amplify the basic concurrency, prioritizing high-resource-consuming tasks to release idle resources; under high load, coefficient K2 is used to compress the concurrency, prioritizing low-resource-consuming tasks to avoid overload. When the historical average resource utilization rates of multiple tasks are close, further dynamic selection is performed based on the estimated execution time and configuration time, forming a dynamic scheduling mechanism. In the smart station scenario, this dynamic scheduling mechanism manifests as follows: urgent tasks in the conditional subqueue can immediately seize execution resources, while regular tasks are executed sequentially, ensuring high responsiveness of core business operations while achieving refined management of resource costs, ultimately achieving dual optimization of task execution efficiency and system stability.

[0039] In one optional implementation, if the resources do not meet the concurrency requirements, the M tasks to be executed are scheduled according to the corresponding estimated execution time, including: if the resources do not meet the concurrency requirements, the M tasks to be executed are divided into short tasks, medium tasks, and long tasks according to the estimated execution time; N1 short tasks are selected with a second step length T1, N2 medium tasks are selected with a first step length T2, and N3 long tasks are selected with a first step length T3, until the resources meet the concurrency requirements and the process exits; wherein T1, T2, and T3 increase sequentially; N1, N2, and N3 decrease sequentially, and N1 + N2 + N3 is less than M.

[0040] If resources do not meet the concurrency requirements, the M tasks are divided into short tasks, medium tasks, and long tasks according to the estimated execution time. For example, tasks with an estimated execution time less than the first step length T1 (e.g., 5 seconds) are classified as short tasks, tasks with an estimated execution time greater than T1 and less than the second step length T2 (e.g., 30 seconds) are classified as medium tasks, and tasks with an estimated execution time greater than T2 are classified as long tasks.

[0041] For short tasks, a high-frequency small-window strategy is adopted, setting a relatively small time-window interval T1. Each time, N1 (e.g., 5 - 10) short tasks are taken in sequence for execution, quickly releasing resources to handle subsequent continuously arriving short tasks. For medium and long tasks, a medium-frequency standard-window strategy is adopted. Each time, N2 (e.g., 1 - 3) medium tasks (such as 1 - 3) are taken in sequence to balance the scheduling frequency and resource utilization efficiency. For long tasks, a sequential execution strategy is adopted. Each time, only N3 (e.g., 1) long task is selected. After the long task is completed, the next long task is selected for execution. Among them, N1, N2, and N3 are all natural numbers, and the sum of N1, N2, and N3 is less than M. When resources are limited, high-efficiency execution of short tasks is prioritized. At the same time, a stepped screening mechanism with different step lengths (T1 < T2 < T3) and quantities (N1 > N2 > N3) can avoid the risk of resource deadlock caused by batch execution of long-duration tasks and improve the overall throughput by gradually releasing resource slots, ultimately achieving a dual optimization of resource utilization rate and task completion rate.

[0042] Embodiment 3 Figure 3 FIG. 6 is a schematic structural diagram of a dynamic adjustment device for a task queue according to Embodiment 3 of the present application. This embodiment is applicable to the situation of scheduling tasks in an intelligent station operation management software platform such as a subway. The dynamic adjustment device for the task queue can be implemented in the form of hardware and / or software, and the device can be configured in a computer device. Refer to Figure 3 , the specific structure of the dynamic adjustment device 300 for the task queue is as follows: A pre-execution task queue module 310 generates tasks based on task configuration information and stores the tasks in the pre-execution task queue; A task execution queue module 320 is used to monitor the tasks in the pre-execution task queue in real time and store the tasks that meet the execution conditions in the task execution queue; An estimated execution duration module 330 is used to determine an estimation coefficient of a task according to the actual execution duration of the task in the last time and the historical average execution duration, and determine the estimated execution duration of the task according to the historical average execution duration and the estimation coefficient; A pending execution task module 340 is used to determine an executable task amount M according to the real-time resource load of the server, the historical average resource load of the task, and the number of tasks being executed by the server, and select M pending execution tasks from the task execution queue; A concurrent requirement determination module 350 is used to determine whether the resources meet the concurrent requirements of the M pending execution tasks according to the historical average resource load of the M pending execution tasks and the real-time resource load; A task scheduling module 360 is used to, if the resources do not meet the concurrent requirements, schedule the M pending execution tasks according to the corresponding estimated execution duration.

[0043] In one optional implementation, the pre-execution task queue includes a first condition sub-queue and a first time-order sub-queue; the first condition sub-queue is located at the head of the pre-execution task queue, and the first time-order sub-queue is located at the tail of the queue; the first time-order sub-queue may include a time-conflict sub-queue, each of the time-conflict sub-queues including multiple time-ordered tasks with the same timestamp, and the multiple time-ordered tasks are sorted according to task weight; The task execution queue includes a second condition subqueue and a second time-order subqueue; the second condition subqueue is located at the head of the task execution queue, and the second time-order subqueue is located at the tail of the queue. Time-order tasks in the time conflict subqueue are sorted by timestamp priority, and tasks with the same timestamp are sorted by task weight priority.

[0044] In one optional implementation, the estimated execution time module 330 includes: The duration difference unit is used to subtract the historical average execution time from the actual execution time of the task in the previous execution to obtain the duration difference; The current coefficient unit is used to divide the duration difference by the previous actual execution duration to obtain the estimated coefficient of the task, and the sum of the estimated coefficient and the base coefficient is used as the current coefficient of the task. The estimated execution time unit is used to multiply the historical average execution time of the task by the current coefficient of the task to obtain the estimated execution time of the task.

[0045] In one alternative implementation, the task module 340 to be executed includes: The concurrency unit is used to determine the current load type based on the server's real-time resource load, and to determine the current task concurrency N using the current coefficient corresponding to the current load type and the basic task concurrency L0. The executable task quantity unit is used to subtract the number of tasks N0 that the server is currently executing from the current concurrent task quantity N to obtain the executable task quantity M; The task-to-be-executed unit is used to select M tasks to be executed from the task execution queue based on the current load type and the historical average resource load of the task.

[0046] In one optional implementation, if the current load type is low load, then the current coefficient is K1; if the current load type is high load, then the current coefficient is K2; K1 is greater than 1, K2 is less than 1, and both K1 and K2 are negatively correlated with the real-time resource load of the server. The task unit to be executed is specifically used for: If the current load type is low load, tasks with higher historical average resource utilization are selected first; if the current load type is high load, tasks with lower historical average resource utilization are selected first; if the current load type is normal load, tasks are selected according to their order in the task execution queue. If the historical average resource utilization of multiple tasks is similar, the task with the shorter estimated execution time shall be selected first. If the historical average resource utilization and estimated execution time of multiple tasks are similar, the task with the earlier configuration time shall be selected first.

[0047] In one alternative implementation, the task scheduling module 360 ​​includes: The task partitioning unit is used to divide the M tasks to be executed into short tasks, medium tasks, and long tasks according to the estimated execution time if the resources do not meet the concurrency requirements. The task invocation unit is used to select N1 short tasks with a second step length T1, N2 medium tasks with a first step length T2, and N3 long tasks with a first step length T3, until the resources meet the concurrency requirements and exit. Among them, T1, T2, and T3 increase in sequence; N1, N2, and N3 decrease in sequence, and N1+N2+N3 is less than M.

[0048] In one optional embodiment, the device 300 further includes a special task scheduling module, which is specifically used for: In response to a special task, determine whether the special task requirements are met based on the server's real-time resource load and the historical average resource load of the special task. If the special task requirements are met, then the special task shall be executed; If the special task requirements are not met, the currently executing task is terminated, and the special task is executed.

[0049] The technical solution provided in this application dynamically adjusts the queue execution order in real time based on key parameters such as task priority, resource availability, and time constraints. When a high-priority, urgent special task is detected, the system intelligently identifies it and automatically inserts it into the optimal execution position to ensure timely response and avoid delays in critical tasks. Simultaneously, the system continuously monitors the real-time resource load of the server, prioritizing resource-intensive tasks during periods of ample resource availability to prevent efficiency degradation due to resource contention. This two-way adjustment mechanism significantly improves task processing efficiency and shortens average waiting time, while effectively balancing resource load. It avoids system overload caused by task accumulation and reduces cost waste caused by resource idleness, ultimately achieving a dual improvement in task timeliness and overall system performance.

[0050] The task queue dynamic adjustment device provided in this application embodiment can execute the task queue dynamic adjustment method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of executing the task queue dynamic adjustment method.

[0051] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product. The computer program product includes a computer program that, when executed by a processor, implements any of the dynamic task queue adjustment methods provided in the embodiments of this application.

[0052] Example 4 Figure 4 This is a schematic diagram of the structure of an electronic device 410 implementing the dynamic adjustment method for the task queue according to embodiments of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0053] like Figure 4 As shown, the electronic device 410 includes at least one processor 411 and a memory, such as a read-only memory (ROM) 412 or a random access memory (RAM) 413, communicatively connected to the at least one processor 411. The memory stores computer programs executable by the at least one processor. The processor 411 can perform various appropriate actions and processes based on the computer program stored in the ROM 412 or loaded from storage unit 418 into the RAM 413. The RAM 413 may also store various programs and data required for the operation of the electronic device 410. The processor 411, ROM 412, and RAM 413 are interconnected via a bus 414. An input / output (I / O) interface 415 is also connected to the bus 414.

[0054] Multiple components in electronic device 410 are connected to I / O interface 415, including: input unit 416, such as keyboard, mouse, etc.; output unit 417, such as various types of displays, speakers, etc.; storage unit 418, such as disk, optical disk, etc.; and communication unit 419, such as network card, modem, wireless transceiver, etc. Communication unit 419 allows electronic device 410 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0055] Processor 411 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 411 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 411 performs the various methods and processes described above, such as the dynamic adjustment method of task queues.

[0056] In some embodiments, the dynamic adjustment method for the task queue can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 418. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 410 via ROM 412 and / or communication unit 419. When the computer program is loaded into RAM 413 and executed by processor 411, one or more steps of the dynamic adjustment method for the task queue described above can be performed. Alternatively, in other embodiments, processor 411 can be configured as the dynamic adjustment method for the task queue by any other suitable means (e.g., by means of firmware).

[0057] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0058] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0059] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, 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 of the foregoing.

[0060] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0061] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0062] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0063] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0064] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for dynamically adjusting a task queue, characterized in that, include: Tasks are generated based on task configuration information and stored in a pre-execution task queue; The tasks in the pre-execution task queue are monitored in real time, and tasks that meet the execution conditions are stored in the task execution queue. Based on the actual execution time of the task in the previous execution and the historical average execution time, the prediction coefficient of the task is determined, and based on the historical average execution time and the prediction coefficient, the estimated execution time of the task is determined. Based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, the number of executable tasks M is determined, and M tasks to be executed are selected from the task execution queue. Based on the historical average resource load of the M tasks to be executed and the real-time resource load, determine whether the resources meet the concurrency requirements of the M tasks to be executed. If the resources do not meet the concurrency requirements, the M tasks to be executed will be scheduled according to the corresponding estimated execution time.

2. The method according to claim 1, characterized in that, The pre-execution task queue includes a first condition sub-queue and a first time-order sub-queue; the first condition sub-queue is located at the head of the pre-execution task queue, and the first time-order sub-queue is located at the tail of the queue; the first time-order sub-queue may include a time-conflict sub-queue, each of the time-conflict sub-queues includes multiple time-ordered tasks with the same timestamp, and the multiple time-ordered tasks are sorted according to task weight; The task execution queue includes a second condition subqueue and a second time-order subqueue; the second condition subqueue is located at the head of the task execution queue, and the second time-order subqueue is located at the tail of the queue. Time-order tasks in the time conflict subqueue are sorted by timestamp priority, and tasks with the same timestamp are sorted by task weight priority.

3. The method according to claim 1, characterized in that, Based on the task's actual execution time in the previous run and its historical average execution time, a prediction coefficient for the task is determined. Then, based on the historical average execution time and the prediction coefficient, the estimated execution time of the task is determined, including: Subtract the historical average execution time from the actual execution time of the task in the previous execution to obtain the duration difference; Divide the duration difference by the previous actual execution duration to obtain the task's estimated coefficient, and use the sum of the estimated coefficient and the base coefficient as the task's current coefficient. The estimated execution time of a task is obtained by multiplying its historical average execution time by the current coefficient of the task.

4. The method according to claim 1, characterized in that, Based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, the number of executable tasks M is determined, and M tasks to be executed are selected from the task execution queue, including: The current load type is determined based on the server's real-time resource load, and the current task concurrency N is determined using the current coefficient corresponding to the current load type and the basic task concurrency L0. Subtract the number of tasks N0 that the server is currently executing from the current number of concurrent tasks N to obtain the number of executable tasks M. Based on the current load type and the historical average resource load of the task, select M tasks to be executed from the task execution queue.

5. The method according to claim 4, characterized in that, If the current load type is low load, then the current coefficient is K1; if the current load type is high load, then the current coefficient is K2; K1 is greater than 1, K2 is less than 1, and both K1 and K2 are negatively correlated with the real-time resource load of the server. Based on the current load type and the historical average resource load of the task, select M tasks to be executed from the task execution queue, including: If the current load type is low load, tasks with higher historical average resource utilization are selected first; if the current load type is high load, tasks with lower historical average resource utilization are selected first; if the current load type is normal load, tasks are selected according to their order in the task execution queue. If the historical average resource utilization of multiple tasks is similar, the task with the shorter estimated execution time shall be selected first. If the historical average resource utilization and estimated execution time of multiple tasks are similar, the task with the earlier configuration time shall be selected first.

6. The method according to claim 1, characterized in that, If resources do not meet the concurrency requirements, the M tasks to be executed are scheduled according to the corresponding estimated execution time, including: If resources do not meet the concurrency requirements, the M tasks to be executed will be divided into short tasks, medium tasks and long tasks according to the estimated execution time. Select N1 short tasks with a second step length T1, select N2 medium tasks with a first step length T2, and select N3 long tasks with a first step length T3, until the resources meet the concurrency requirements and exit. Among them, T1, T2, and T3 increase in sequence; N1, N2, and N3 decrease in sequence, and N1+N2+N3 is less than M.

7. The method according to claim 1, characterized in that, The method further includes: In response to a special task, determine whether the special task requirements are met based on the server's real-time resource load and the historical average resource load of the special task. If the special task requirements are met, then the special task shall be executed; If the special task requirements are not met, the currently executing task is terminated, and the special task is executed.

8. A dynamic adjustment device for a task queue, characterized in that, include: The pre-execution task queue module generates tasks based on task configuration information and stores the tasks in the pre-execution task queue; The task execution queue module is used to monitor the tasks in the pre-execution task queue in real time and store the tasks that meet the execution conditions into the task execution queue. The estimated execution time module is used to determine the estimated coefficient of a task based on the actual execution time of the task in the previous execution and the historical average execution time, and to determine the estimated execution time of the task based on the historical average execution time and the estimated coefficient. The task-to-be-executed module is used to determine the number of executable tasks M based on the server's real-time resource load, the historical average resource load of the tasks, and the number of tasks currently being executed by the server, and to select M tasks to be executed from the task execution queue. The concurrency requirement determination module is used to determine whether the resources meet the concurrency requirements of the M tasks to be executed based on the historical average resource load of the M tasks to be executed and the real-time resource load. The task scheduling module is used to schedule the M tasks to be executed according to the estimated execution time if the resources do not meet the concurrency requirements.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the dynamic adjustment method for the task queue as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, this program implements the dynamic adjustment method for the task queue as described in any one of claims 1-7.

Images