Unified management method and system for RTos timers
By managing RTOS timed tasks through a global timer, sorting them by timestamp and triggering callback functions, the problem of chaotic RTOS timer management is solved, task scheduling efficiency and system response speed are improved, and high real-time performance and stability are achieved in high-concurrency scenarios.
Patent Information
- Application Number
- CN202511027002.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-24
- Publication Date
- 2025-11-11
AI Technical Summary
Existing RTOS timers are poorly managed in multi-task concurrent scenarios, resulting in significant resource waste. They lack a unified task management queue and dynamic sorting capabilities, making it difficult to meet the requirements of high concurrency and high-precision scheduling.
A global timer is introduced to manage scheduled tasks through a task queue. Tasks are sorted by timestamp and automatically triggered with callback functions. Task retry and cancellation mechanisms are supported. Multi-level sorting and adaptive retry strategies are adopted to improve task scheduling efficiency and system response speed.
It enables the orderly scheduling of timed tasks, avoids resource waste, improves the real-time performance and stability of the system, ensures timely task response, and optimizes resource utilization.
Smart Images
Figure CN120929209A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of timer technology, and specifically to a unified management method and system for RTos timers. Background Technology
[0002] Real-time operating systems (RTOS) are widely used in embedded systems, IoT devices, and industrial control applications. One of their core tasks is to accurately execute specified tasks at defined times or within a given period. To meet this requirement, RTOS typically provides a timer mechanism to implement functions such as scheduled task execution, timeout control, and periodic execution.
[0003] In existing technologies, RTOS timers typically rely on multiple timer types running in parallel, such as hardware timers, interrupt-driven timers, and software timers. While this design offers some flexibility, it can easily lead to chaotic timer management, resource waste, and code maintenance difficulties in complex scenarios where multiple timers exist simultaneously and multiple tasks need to register their timing behaviors. This is especially true when the number of tasks changes frequently or the system load fluctuates, making it difficult to guarantee the determinism of task scheduling and the efficiency of system response.
[0004] In addition, traditional RTos timer mechanisms lack a unified task management queue, have limited sorting and scheduling capabilities for tasks to be executed, do not support timestamp-based dynamic sorting management and state tracking during task execution, and are difficult to adapt to the actual needs of high concurrency and high-precision scheduling. Summary of the Invention
[0005] (I) Purpose of the Invention
[0006] The purpose of this invention is to provide a unified RTOS timer management method and system that centrally manages scheduled tasks through a global timer, sorts tasks by timestamp, automatically triggers callback functions for execution and removal, improves task scheduling efficiency and system response speed, avoids duplicate scheduling and resource waste, and has high real-time performance, reliability and scalability, making it suitable for multi-task concurrent scenarios.
[0007] (II) Technical Solution
[0008] To address the above problems, this invention provides a unified management method for RTOS timers, comprising:
[0009] Create a global timer, which includes a task queue that stores information about tasks to be executed, including task timestamps and callback functions.
[0010] Register tasks to be executed, and add the tasks to the task queue according to the task timestamp;
[0011] Based on the system time of the system clock and the timestamps of the tasks to be executed in the task queue, the corresponding callback function is called to execute the task.
[0012] When the current system time is detected to be equal to or greater than the timestamp of a task to be executed in the task queue, the task to be executed is removed from the task queue.
[0013] In another aspect, preferably, the invention further includes: when there are multiple tasks to be executed within the same task timestamp, a secondary sorting is performed based on the user setting or a preset task type when registering the tasks to be executed;
[0014] The secondary sorting includes:
[0015] Sort the tasks according to their priority set by the user during registration, from highest to lowest.
[0016] If the tasks have the same priority, they are sorted according to the preset task type level based on the task type to be executed;
[0017] If the task types are of the same level, they are sorted according to the order of their registration time. In another aspect of the invention, preferably, the method includes a task retry mechanism. When a callback function fails, the task is reinserted into the task queue after a set retry interval according to a preset retry strategy, until the maximum number of retries is reached.
[0018] In another aspect of the present invention, preferably,
[0019] The retry strategies include: fixed-interval retry, exponential backoff retry, and adaptive retry mode;
[0020] The interval between the fixed-interval retry is a fixed value;
[0021] The interval between the exponential backoff retry is based on the initial interval and increases exponentially with the number of retries.
[0022] The intermediate interval of the adaptive retry is dynamically adjusted according to the previous failure type and the current load index to determine the next retry interval.
[0023] In another aspect of the invention, preferably, the intermediate interval of the exponential backoff retry is expressed using the following formula:
[0024] ΔT n =Δt×2 n
[0025] Where, ΔTn Δt represents the interval between the nth exponential backoff retry, Δt represents the initial interval, and n represents the sequence number of the retry.
[0026] In another aspect of the present invention, preferably,
[0027] The failure types include peripheral response timeout, resource usage conflict, communication failure, and illegal parameters;
[0028] The adaptive retry interval is dynamically adjusted based on the previous failure type and the current load metrics, including:
[0029] Different failure types are assigned corresponding preset risk scores;
[0030] Calculate the real-time load score based on the current load metrics;
[0031] The scheduling score is obtained by combining the preset risk score and the real-time load score;
[0032] The pre-defined retry interval table is consulted based on the score to determine the retry interval for the next retry.
[0033] In another aspect of the present invention, preferably,
[0034] The calculation of real-time load score based on current load metrics includes:
[0035] Obtain multiple load metrics, including CPU utilization, task queue length, memory usage, and interrupt frequency;
[0036] Multiple load metrics are normalized separately to obtain normalized values for the multiple load metrics.
[0037] A real-time load score is obtained based on the weighting coefficients of multiple load metrics and the normalized values of multiple load metrics.
[0038] In another aspect of the present invention, preferably,
[0039] Before removing the task to be executed from the task queue, the process includes:
[0040] The execution status of the callback function of the task to be executed is marked and recorded, and its execution result information is written to the system log module.
[0041] In another aspect of the present invention, preferably,
[0042] The method also includes a task cancellation mechanism, which obtains a unique task identifier when a task is registered;
[0043] Based on the unique task identifier, obtain the tasks to be executed in the task queue that match the unique task identifier;
[0044] Remove the task to be executed from the task queue to complete the cancellation.
[0045] In another aspect, preferably, an RTos timer unified management system includes:
[0046] Creation Module: Creates a global timer, which includes a task queue that stores information about tasks to be executed, including task timestamps and callback functions;
[0047] Sorting module: Register tasks to be executed, and add the tasks to be executed into the task queue according to the task timestamp for sorting;
[0048] The calling module: Based on the system time of the system clock and the timestamp of the tasks to be executed in the task queue, it calls the corresponding callback function to execute the task;
[0049] Remove module: When the current system time is detected to be equal to or greater than the timestamp of a task to be executed in the task queue, the task to be executed is removed from the task queue.
[0050] (III) Beneficial Effects
[0051] The above-described technical solution of the present invention has the following beneficial technical effects:
[0052] This invention introduces a global timer to uniformly manage various timed tasks, avoiding the resource waste caused by the repeated creation and management of multiple timers in the system. By sorting the tasks to be executed according to their timestamps and storing them in a task queue, the orderly scheduling of timed tasks can be achieved. The system matches the current system clock with the task timestamp and automatically triggers the corresponding callback function to execute the task, ensuring timely task response and improving the system's real-time performance and execution efficiency. After execution, the task is automatically removed from the queue, preventing invalid tasks from occupying system resources and improving the overall stability and maintainability of the system. Attached Figure Description
[0053] Figure 1 This is an overall flowchart of one embodiment of the present invention. Detailed Implementation
[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.
[0055] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0056] In the description of this invention, it should be noted that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0057] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0058] The invention will now be described in more detail with reference to the accompanying drawings. In the various drawings, the same elements are indicated by similar reference numerals. For clarity, the various parts in the drawings are not drawn to scale.
[0059] Example 1
[0060] A unified management method for RTOS timers. Figure 1 An overall flowchart of one embodiment of the present invention is shown, as follows: Figure 1 As shown, it includes:
[0061] A global timer is created, comprising a task queue that stores information about tasks to be executed. This task information includes a task timestamp and a callback function. The task timestamp indicates the planned execution time of the task, and the callback function executes the specific task operation logic. When registering tasks, the system sorts and inserts them into the queue based on their timestamps to ensure that tasks are executed sequentially.
[0062] Register tasks to be executed and add them to the task queue according to their timestamps for sorting. Users or the system can register a new task to be executed through an interface and insert it into the task queue of the global timer. When adding tasks, they are sorted and inserted according to their timestamps to ensure that the task queue is arranged in chronological order of execution, thereby facilitating subsequent sequential scanning and trigger judgment.
[0063] Based on the system time from the system clock and the timestamps of the tasks awaiting execution in the task queue, the system invokes the corresponding callback function to execute the task. It also determines whether there are any tasks that need immediate execution based on the system time from the system clock and the timestamps of each task awaiting execution in the task queue. The system clock is a high-precision timing module provided internally by the RTOS, providing a continuously incrementing current system time. When the system time reaches the timestamp of a certain task, the system triggers the corresponding callback function to execute the operation bound to the task.
[0064] When the current system time reaches or exceeds the timestamp of a task in the task queue, the task is removed from the task queue. Once a task is completed, it is immediately removed from the task queue to release resources and prevent duplicate triggering. The queue management mechanism can be implemented based on data structures such as linked lists, priority queues, or red-black trees; the specific structure can be optimized according to actual needs. Before removing the task from the task queue, the following steps are taken:
[0065] The execution status of the callback function for the task to be executed is marked and recorded, and its execution result information is written to the system log module. First, the task's callback function is called and its execution status is marked. Simultaneously, the execution result, such as success, failure, and time elapsed, is written to the system log module for subsequent auditing or debugging. After the task is completed, it is removed from the queue to avoid duplicate execution.
[0066] Furthermore, in this embodiment, the method also includes a task cancellation mechanism, whereby a unique task identifier is obtained when a task is registered.
[0067] Based on the unique task identifier, the system retrieves the task to be executed from the task queue that matches the unique task identifier; it then removes the task from the task queue, completing the cancellation. When registering each task, a unique identifier is generated and returned, uniquely corresponding to one task entity in the task queue. When a user or upper-layer application issues a cancellation command, the system can search for the corresponding task in the task queue using the passed-in unique task identifier and remove it, thus canceling the task. The cancellation operation is real-time and thread-safe, ensuring it does not affect the normal execution of other tasks in the queue.
[0068] Furthermore, in this embodiment, it also includes: when there are multiple tasks to be executed within the same task timestamp, the tasks to be executed are sorted a second time based on the user setting or the preset task type when they are registered;
[0069] The secondary sorting includes:
[0070] Tasks are sorted from highest to lowest priority according to the user-defined priority during registration. If tasks have the same priority, they are sorted by their type according to a preset task type level. If task type levels are the same, they are sorted by their registration time. When multiple tasks have the same timestamp during registration, meaning multiple tasks need to be triggered simultaneously when the system time reaches that timestamp, a multi-layered secondary sorting rule is used to ensure the determinism and rationality of task execution, avoiding resource contention or abnormal system behavior that may result from uncertain execution order. Specifically, the system first sorts tasks according to their priority as set by the user during registration. Higher priority values indicate greater urgency or higher system response requirements, and these tasks are executed first via callback functions. Second, if multiple tasks have the same priority, the system further sorts them based on preset task type levels. These levels are defined according to the system design, categorizing tasks by their real-time requirements, resource needs, and other factors, ensuring critical tasks are executed first. Finally, if both priority and task type level are the same, the system prioritizes tasks based on their registration time, with earlier registered tasks executed first. This multi-layered sorting mechanism flexibly adapts to real-time scheduling needs in different application scenarios, further enhancing the robustness and controllability of the unified timer management system, avoiding task conflicts and execution disorder, and improving system stability and user experience.
[0071] Furthermore, in this embodiment, the method includes a task retry mechanism. When a callback function fails to execute, the task to be executed is reinserted into the task queue after a set retry interval according to a preset retry strategy, until the maximum number of retries is reached. This is suitable for callback functions that fail on their first execution, enabling automatic retrying according to a system preset strategy to avoid task loss or system anomalies due to momentary exceptions or temporary resource unavailability. When a callback function of a task to be executed fails to execute, such as returning an error code, abnormal interruption, or no response, the exception type and failure time are first recorded, and a determination is made according to the preset retry strategy whether a task retry is necessary. If a retry is deemed necessary, the next execution time is calculated based on the current time and the set retry interval, which can be a fixed value, an incremental interval, or an exponential backoff strategy, and the task is reinserted into the corresponding new timestamp position in the global task queue. The task sorting mechanism is still followed during insertion to ensure that the task is rescheduled and executed at the correct time and priority. Each task is bound to a maximum retry limit. The retry count is incremented by one after each failure. If the number of retryes for a task exceeds the set maximum retry limit, the system can mark the task as "permanently failed" and trigger corresponding error reporting, logging, or fault recovery processes so that system administrators or upper-level applications can handle it further.
[0072] Furthermore, in this embodiment, the retry strategy includes: fixed interval retry, exponential backoff retry, and adaptive retry mode;
[0073] The interval between retry attempts is a fixed value. In fixed interval retry mode, the interval between all retry operations is a fixed value, which is generally suitable for scenarios where the cause of task failure is relatively certain and the recovery time is controllable. After recording the failure event, the system reschedules the failed task for execution at a set time interval (e.g., 5 seconds) until the maximum number of retries is reached.
[0074] The intermediate interval for the exponential backoff retry is based on the initial interval and increases exponentially with the number of retries; the intermediate interval for the exponential backoff retry is expressed by the following formula:
[0075] ΔT n =Δt×2 n
[0076] Where, ΔT n Δt represents the interval between the nth exponential backoff retry, Δt represents the initial interval, and n represents the retry number. The exponential backoff retry mode is primarily used to handle tasks with high-frequency failures or those facing instantaneous resource contention risks. After each failure, the system gradually increases the retry interval to avoid putting greater pressure on the system or creating a request storm.
[0077] The adaptive retry interval is dynamically adjusted based on the previous failure type and current load metrics. After a task fails, the retry interval is dynamically adjusted based on the cause of failure and the current system load, effectively avoiding excessive consumption of system resources and task conflicts, and improving the adaptability and intelligence of overall task scheduling. The failure types include peripheral response timeout, resource conflict, communication failure, and illegal parameters. Peripheral response timeout refers to task failure caused by prolonged unresponsiveness of external devices; resource conflict refers to failure caused by critical system resources such as memory and bus being occupied and inaccessible by other tasks; communication failure refers to interruption or data loss during network or inter-process communication; and illegal parameters refer to exceptions caused by parameters passed to the task that do not conform to logic or expected format.
[0078] The adaptive retry interval is dynamically adjusted based on the previous failure type and the current load metrics, including:
[0079] Different failure types are assigned corresponding preset risk scores; based on the type of failure in the previous task execution, a preset risk score is assigned to the failure type. The risk score reflects the potential impact of that type of failure on system operation; for example, peripheral response timeouts correspond to higher risk scores, while illegal parameters correspond to relatively lower risk scores.
[0080] Calculate a real-time load score based on current load metrics, including:
[0081] Obtain multiple load metrics, including CPU utilization, task queue length, memory usage, and interrupt frequency;
[0082] Multiple load metrics are normalized separately to obtain normalized values for each load metric. The normalization of each metric ensures that the values are within the same dimension, facilitating weighted summation.
[0083] A real-time load score is obtained based on the weighting coefficients and normalized values of multiple load metrics. Each metric has a pre-set weighting coefficient, representing its relative importance in the real-time load assessment.
[0084] The scheduling score is obtained by combining the preset risk score and the real-time load score; the scheduling score is obtained by weighted summation.
[0085] The system uses a pre-defined retry interval table to determine the retry interval for the next retry, based on the score. A lookup operation is performed within the pre-defined retry interval table to obtain the corresponding retry interval value, and the next retry time for the task is set accordingly. This method allows the system to appropriately delay retries under high load and quickly recover under low load, improving the robustness and execution efficiency of the overall scheduling system.
[0086] This invention introduces a global timer to uniformly manage various timed tasks, avoiding the resource waste caused by the repeated creation and management of multiple timers in the system. By sorting the tasks to be executed according to their timestamps and storing them in a task queue, the orderly scheduling of timed tasks can be achieved. The system matches the current system clock with the task timestamp and automatically triggers the corresponding callback function to execute the task, ensuring timely task response and improving the system's real-time performance and execution efficiency. After execution, the task is automatically removed from the queue, preventing invalid tasks from occupying system resources and improving the overall stability and maintainability of the system.
[0087] Example 2
[0088] A unified management system for RTOS timers, comprising:
[0089] Creation Module: Creates a global timer, which includes a task queue that stores information about tasks to be executed, including task timestamps and callback functions;
[0090] Sorting module: Register tasks to be executed, and add the tasks to be executed into the task queue according to the task timestamp for sorting;
[0091] The calling module: Based on the system time of the system clock and the timestamp of the tasks to be executed in the task queue, it calls the corresponding callback function to execute the task;
[0092] Remove module: When the current system time is detected to be equal to or greater than the timestamp of a task to be executed in the task queue, the task to be executed is removed from the task queue.
[0093] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.
[0094] The present invention has been described above with reference to embodiments thereof. However, these embodiments are merely illustrative and not intended to limit the scope of the invention. The scope of the invention is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of the invention, and all such substitutions and modifications should fall within the scope of the invention.
[0095] Although embodiments of the present invention have been described in detail, it should be understood that various changes, substitutions, and modifications can be made to the embodiments of the present invention without departing from the spirit and scope of the invention.
[0096] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.
Claims
1. A unified management method for RTOS timers, characterized in that, include: Create a global timer, which includes a task queue that stores information about tasks to be executed, including task timestamps and callback functions. Register tasks to be executed, and add the tasks to the task queue according to the task timestamp; Based on the system time of the system clock and the timestamps of the tasks to be executed in the task queue, the corresponding callback function is called to execute the task. When the current system time is detected to be equal to or greater than the timestamp of a task to be executed in the task queue, the task to be executed is removed from the task queue.
2. The unified management method for RTOS timers according to claim 1, characterized in that, Also includes: When there are multiple tasks to be executed within the same task timestamp, the tasks are sorted based on the user's settings when registering the tasks or according to the preset task types. The secondary sorting includes: Sort the tasks according to their priority set by the user during registration, from highest to lowest. If the tasks have the same priority, they are sorted according to the preset task type level based on the task type to be executed; If the task types are of the same level, they will be sorted according to the order of their registration time.
3. The unified management method for RTOS timers according to claim 1, characterized in that: The method includes a task retry mechanism. When the callback function fails to execute, the task to be executed is re-inserted into the task queue after a set retry interval according to a preset retry strategy, until the maximum number of retries is reached.
4. The unified management method for RTOS timers according to claim 3, characterized in that: The retry strategies include: fixed-interval retry, exponential backoff retry, and adaptive retry mode; The interval between the fixed-interval retry is a fixed value; The interval between the exponential backoff retry is based on the initial interval and increases exponentially with the number of retries. The intermediate interval of the adaptive retry is dynamically adjusted according to the previous failure type and the current load index to determine the next retry interval.
5. The unified management method for RTos timers according to claim 4, characterized in that: The interval between indexed backoff retryes is expressed using the following formula: ΔT n =Δt×2 n Where, ΔT n Δt represents the interval between the nth exponential backoff retry, Δt represents the initial interval, and n represents the sequence number of the retry.
6. The unified management method for RTOS timers according to claim 4, characterized in that: The failure types include peripheral response timeout, resource usage conflict, communication failure, and illegal parameters; The adaptive retry interval is dynamically adjusted based on the previous failure type and the current load metrics, including: Different failure types are assigned corresponding preset risk scores; Calculate the real-time load score based on the current load metrics; The scheduling score is obtained by combining the preset risk score and the real-time load score; The pre-defined retry interval table is consulted based on the score to determine the retry interval for the next retry.
7. The unified management method for RTos timers according to claim 6, characterized in that: The calculation of real-time load score based on current load metrics includes: Obtain multiple load metrics, including CPU utilization, task queue length, memory usage, and interrupt frequency; Multiple load metrics are normalized separately to obtain normalized values for the multiple load metrics. A real-time load score is obtained based on the weighting coefficients of multiple load metrics and the normalized values of multiple load metrics.
8. The unified management method for RTOS timers according to claim 6, characterized in that: Before removing the task to be executed from the task queue, the process includes: The execution status of the callback function of the task to be executed is marked and recorded, and its execution result information is written to the system log module.
9. The unified management method for RTos timers according to claim 1, characterized in that: The method also includes a task cancellation mechanism, which obtains a unique task identifier when a task is registered; Based on the unique task identifier, obtain the tasks to be executed in the task queue that match the unique task identifier; Remove the task to be executed from the task queue to complete the cancellation.
10. A unified management system for RTOS timers, characterized in that, include: Creation Module: Creates a global timer, which includes a task queue that stores information about tasks to be executed, including task timestamps and callback functions; Sorting module: Register tasks to be executed, and add the tasks to be executed into the task queue according to the task timestamp for sorting; The calling module: Based on the system time of the system clock and the timestamp of the tasks to be executed in the task queue, it calls the corresponding callback function to execute the task; Remove module: When the current system time is detected to be equal to or greater than the timestamp of a task to be executed in the task queue, the task to be executed is removed from the task queue.