Timeout control method and system with security cleaning mechanism for RTOS (Real Time Operating System)
By introducing a static TCB array and a dual-semaphore safety cleanup mechanism into the embedded real-time system, the system instability caused by function execution timeout is solved, enabling precise control of function execution time and safe resource recovery, thereby improving the safety and reliability of the UAV flight control system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-22
- Publication Date
- 2026-04-07
AI Technical Summary
Existing technologies in embedded real-time systems, especially UAV flight control systems, cannot effectively solve the system instability and security problems caused by function execution timeouts. Existing solutions, such as watchdog reset, are too crude or internal checkpoints are unreliable, and cannot achieve safe state recovery and resource release.
A strategy combining static TCB arrays and dynamic task creation is adopted. Through dual semaphores and a safe cleanup mechanism, efficient, safe, and non-intrusive timeout control is performed on function execution, including task semaphores and completion semaphores, to ensure on-demand resource allocation and state recovery.
It enables precise monitoring of function execution time, avoids performance overhead and memory fragmentation caused by frequent task creation, ensures system security, real-time performance and reliability, supports fine-grained "function-level" control, and improves the overall reliability and security of the system.
Smart Images
Figure CN121807601A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of embedded real-time systems, and in particular to a timeout control method and system with a safe cleanup mechanism for an RTOS, which is suitable for related fields such as system safety and computer program design. BACKGROUND
[0002] In an embedded system based on an RTOS (Real-Time Operating System), especially in a UAV flight control system with extremely high requirements for real-time performance and reliability, it is crucial to ensure the stable operation of core functions. The flight control system relies on the cooperative work of a series of periodic tasks such as state estimation, attitude calculation, control law operation, and navigation decision. However, there are some operations in the system that may inevitably block or execute for a long time, for example: Sensor data reading: When reading gyroscope, accelerometer, magnetometer, or barometer data through I2C / SPI bus, it may be waiting for a long time due to hardware pin interference, sensor non-response, or bus conflict.
[0003] External communication: When communicating with a data radio, a ground station, or other UAVs, it may be trapped in a circular wait due to poor signal quality, protocol parsing errors, etc.
[0004] Complex algorithms or third-party library functions: When calling some high-computational-density or logically complex algorithms such as visual processing or path planning, unexpected long execution time or even dead loops may occur due to specific inputs.
[0005] In a typical UAV flight control architecture based on an ARM Cortex-M platform and using an RTOS as the real-time operating system, any exception of the above functions may lead to catastrophic consequences.
[0006] In summary, in safety-critical systems such as UAV flight control, the existing technical solutions have fundamental defects. The watchdog reset is too rough, and forcibly terminating the task may introduce a fatal secondary fault, while the internal checkpoint is neither practical nor reliable. SUMMARY
[0007] In view of the above analysis, the present application aims to provide a technical solution that can efficiently, safely, and non-invasively control the execution of any function in an RTOS, ensuring that the core functions of the system are not affected.
[0008] In one aspect, the present application provides a timeout control method for an RTOS with a safe cleanup mechanism, which includes the following steps: Obtain the task ID of the caller through a pre-set safe call interface; The corresponding TCB is found in the Thread Control Block (TCB) array based on the caller's task ID. Check whether a delegated task has been created in the obtained TCB. If not, create a new delegated task according to the caller's task priority and execute it; if it has been created, reuse the existing delegated task and execute it directly. After the delegated task is executed normally, the TCB is marked as unused, and the delegated task of the TCB is marked as waiting for the caller to reuse it. If the delegated task times out, a security cleanup mechanism will be used to complete the timeout control.
[0009] Furthermore, the step of searching for the corresponding TCB in the Task Control Block (TCB) array based on the caller task ID includes: firstly, checking if there is a TCB already bound to the caller task ID; if there is, directly acquiring and reusing the TCB; if there is not, searching for the first unused TCB in the array, marking the unused TCB as used, and binding it to the caller task ID.
[0010] Furthermore, the delegated task includes two semaphores; the two semaphores include a task semaphore and a completion semaphore; the priority of the delegated task is the same as the priority of its corresponding caller task.
[0011] Furthermore, the TCB structure stores: caller task ID, delegate task ID, task semaphore ID, completion semaphore ID, target function pointer, cleanup callback function pointer, function parameters, and usage status flags.
[0012] Furthermore, the delegated task is executed in the following manner: the caller task wakes up the delegated task in a waiting state by releasing the task semaphore stored in the TCB. After the delegated task is woken up, it reads the target function pointer and parameters from the TCB and executes the target function. After the target function is executed, it releases the corresponding completion semaphore in the TCB to notify the caller that the task has been completed.
[0013] Furthermore, the normal execution of the delegated task includes: if the caller task acquires a completion semaphore within a preset timeout period, then a successful execution result is returned.
[0014] Furthermore, the security cleanup mechanism includes: If the caller task fails to acquire the completion semaphore within the preset timeout period, then: the caller task first suspends the delegated task, then executes the cleanup callback function to release the resources occupied by the target function, restore the system state, terminate the delegated task, delete the dual semaphores, reset the corresponding TCB to an unused state, and return a timeout error.
[0015] Furthermore, the cleanup callback function is customized by the user according to the characteristics of the target function, and includes at least one of the following resource processing logics: releasing the mutex lock occupied by the target function, reclaiming dynamically allocated memory space, resetting the state of hardware peripherals, and clearing the data buffer.
[0016] Furthermore, the maximum number of TCBs in the TCB array is configured through a macro definition. Users can adjust the value of this macro definition according to the resource constraints and concurrency requirements of the RTOS system to support different numbers of concurrent timeout calls.
[0017] On the other hand, embodiments of the present invention provide a timeout control system with a security cleanup mechanism for an RTOS, comprising: TCB Acquisition Module: Acquires the caller's task ID through a preset secure call interface, and searches for the corresponding TCB in the Task Control Block (TCB) array based on the caller's task ID; The delegated task execution module checks whether a delegated task has been created in the obtained TCB. If not, a new delegated task is created and executed according to the caller's task priority. If a delegated task has been created, the existing delegated task is reused and executed. After the delegated task is executed normally, the task control block TCB remains unused, and the delegated task in the task control block TCB returns to the waiting state for the caller to reuse. The timeout control module is used to complete the timeout control by employing a safety cleanup mechanism when a delegated task times out.
[0018] The beneficial effects of this technical solution are: This invention employs a strategy combining static TCB arrays and dynamic task creation. This avoids the uncertainty of dynamic memory allocation and enables on-demand resource allocation. When the same task is called multiple times, already created delegated tasks can be reused, significantly reducing the performance overhead and memory fragmentation caused by frequent task creation and deletion. It uses dual semaphores—a task semaphore and a completion semaphore—to synchronize the caller's task and delegated task information, avoiding race conditions. A safe cleanup mechanism of suspension, cleanup, and deletion ensures that all necessary state recovery operations are completed before resource release. Through innovative architectural design and security mechanisms, this invention enables precise monitoring and control of the execution time of individual functions, achieving fine-grained control from "system-level reset" to "function-level management." It solves the long-standing timeout control problem plaguing embedded real-time systems, significantly improving security, real-time performance, resource efficiency, and availability, demonstrating high practical value and broad application prospects.
[0019] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description
[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a flowchart of a method according to an embodiment of the present invention; Figure 2 This is a flowchart of the TCB acquisition module of the system according to an embodiment of the present invention; Figure 3 This is a flowchart of the system delegated task execution module according to an embodiment of the present invention; Figure 4 This is a flowchart of the system timeout control module in an embodiment of the present invention. Detailed Implementation
[0021] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.
[0022] In safety-critical systems such as drone flight control, the following practices are mainly relied upon, but they all have shortcomings, which are analyzed and explained in detail below: 1. The shortcomings of the watchdog mechanism and its consequences in drone scenarios: 1) Coarse-grained control directly leads to task failure: The watchdog timer safeguards the "survival" of the entire chip, not just a single function. For example, if an auxiliary function in the attitude calculation task that reads the SPI (Serial Peripheral Interface) temperature sensor becomes blocked, even if the core control loop of the flight controller (such as PID calculation) can still run, the watchdog timer will still reset because the main loop is stuck. This will cause the drone to crash directly, making it impossible to achieve "graceful degradation" or "safe landing".
[0023] 2) Inability to safely restore state and save data: Resetting is devastating. Critical data from the drone's flight (such as current waypoints, black box logs, and sensor calibration parameters) may not have been saved to non-volatile memory. Even more dangerous is that the ESC may receive the last invalid motor control signal at the moment of reset, causing the motors to stop or spin wildly, greatly increasing the safety risk.
[0024] 3) Seriously affects system reliability: It is completely unacceptable for a system to be unexpectedly reset and restarted multiple times due to minor function problems during a long autonomous flight mission.
[0025] 2. The shortcomings of simple task separation and forced termination schemes, and their consequences in drone scenarios: 1) Causes resource leaks and system inconsistencies, leading to a chain of failures: If a failure occurs, the task will be terminated immediately without any cleanup.
[0026] When the task reads data, it acquires a mutex lock on the I2C bus. If it is forcibly terminated, this mutex lock will never be released. Subsequently, when the altitude-keeping task attempts to acquire the I2C lock to read data, it will immediately become permanently blocked. This will cause altitude control to fail, and the drone will be unable to maintain its altitude.
[0027] Dynamic memory leak: If the task has requested memory for data caching, that memory will be permanently lost, gradually depleting the system heap space during long-term flight.
[0028] 2) Abnormal hardware peripheral status: Forced termination may leave the I2C / SPI bus in a half-transmission state, which may cause all subsequent sensor reading tasks using the bus to fail and the sensor data to become completely invalid.
[0029] 3) The solution lacks security and cannot be used for flight control: Since it is impossible to predict which key resources a function will occupy during execution, forced termination is tantamount to "planting a mine". The secondary failures it causes are often more serious than the original function timeout, which does not meet the stringent safety requirements of the flight control system.
[0030] 3. The shortcomings of user-implemented timeout checks and their consequences in drone scenarios: 1) Highly invasive and difficult to maintain: It requires modifying the source code of the sensor driver or algorithm library, inserting a large amount of code unrelated to the functional logic. This undermines the modularity and maintainability of the code and creates significant difficulties for the integration of third-party libraries.
[0031] 2) Ineffective handling of low-level blocking: If the root cause of the timeout is a call to a low-level blocking function (such as waiting for an interrupt signal to complete DMA transfer), the checkpoint inserted in the high-level function cannot interrupt this blocking at all, and the timeout mechanism fails.
[0032] 3) Incomplete implementation: It is difficult to correctly place checkpoints on all possible long paths of the function, which is easy to miss and the reliability cannot be guaranteed.
[0033] Based on the above analysis, the present invention provides a timeout control method and system with a security cleanup mechanism for RTOS.
[0034] A specific embodiment of the present invention discloses a timeout control method with a security cleanup mechanism for an RTOS, the method flow is as follows: Figure 1 As shown, the specific steps include: Obtain the caller's task ID through a pre-defined secure API; The corresponding TCB is found in the Task Control Block (TCB) array based on the caller's task ID. Check whether a delegated task has been created in the obtained TCB. If not, create a new delegated task according to the caller's task priority and execute it; if it has been created, reuse the existing delegated task and execute it directly. After the delegated task is executed normally, the TCB is marked as unused, and the delegated task of the TCB is marked as waiting for the caller to reuse it. If the delegated task times out, a security cleanup mechanism will be used to complete the timeout control.
[0035] In implementation, the secure call interface serves as the unified entry point for users to invoke the timeout control function. Users obtain the caller task ID through this interface, then pass in parameters such as the target function, timeout period, and cleanup callback function to configure the Task Control Block (TCB). Based on the caller task ID, the TCB is located and a delegated task is created. After initiating the request, the caller task waits for the completion semaphore until the target function completes or times out. Receiving the completion semaphore indicates successful execution; otherwise, the cleanup callback function is triggered, releasing resources. After the delegated task starts, it waits for the task semaphore. Once the semaphore is acquired, the target function is executed. After execution, the completion semaphore is released, and the task returns to the state of waiting for the task semaphore. This achieves synchronization between the caller task and the delegated task.
[0036] The method provided in this embodiment enables efficient, secure, and non-intrusive timeout control for the execution of any function in an RTOS. It allows for precise monitoring and control of function execution time, with accuracy depending on the system clock cycle, typically reaching millisecond levels. This fully meets the timing requirements of most embedded real-time applications and avoids the overhead and configuration complexity of additional hardware timers. The non-intrusive aspect means that users do not need to modify the internal implementation of the target function; they only need to call a unified secure call interface and provide cleanup callbacks. This reduces the risk of modifying the existing codebase and improves code maintainability.
[0037] By employing a strategy that combines static TCB arrays with dynamic task creation, the uncertainty of dynamic memory allocation is avoided, while on-demand resource allocation is achieved. When the same task is called multiple times, already created delegate tasks can be reused, greatly reducing the performance overhead and memory fragmentation caused by frequent task creation and deletion.
[0038] Furthermore, the step of searching for the corresponding TCB in the Task Control Block (TCB) array based on the caller task ID includes: firstly, checking if there is a TCB already bound to the caller task ID; if there is, directly acquiring and reusing the TCB; if there is not, searching for the first unused TCB in the array, marking the unused TCB as used, and binding it to the caller task ID.
[0039] Furthermore, the delegated task includes two semaphores: a task semaphore and a completion semaphore. The priority of the delegated task is the same as the priority of its corresponding caller task. The delegated task inherits the priority of the caller task, which reflects delegated execution while avoiding priority inversion issues, ensuring that real-time requirements are met.
[0040] Specifically, the task semaphore is initially set to 0. After the caller task releases the semaphore, it becomes 1, triggering the delegated task blocked on the semaphore to change from the "waiting state" to the "ready state" so as to wake up the delegated task. The completion semaphore is initially set to 0. After the delegated task releases the semaphore, it becomes 1 to notify the caller task that "execution has been completed".
[0041] Specifically, by using a strategy that aligns the priority of the caller task with the priority of the delegated task, when different caller tasks arise, each can execute its corresponding delegated task according to the priority of the caller task, thus preventing high-priority callers from being blocked by low-priority tasks and ensuring real-time response to needs.
[0042] Furthermore, the TCB structure stores: caller task ID, delegate task ID, task semaphore ID, completion semaphore ID, target function pointer, cleanup callback function pointer, function parameters, and usage status flags.
[0043] For example, the Task Control Block (TCB) array is configured through macro definitions, and the specific implementation code is shown below: #define MAX_TCB_NUM 8 / / Maximum number of concurrent timeout calls supported typedef struct { osThreadId_t caller_task_id; / / Caller task ID osThreadId_t worker_task_id; / / Delegated task ID osSemaphoreId_t task_sem; / / Task start semaphore osSemaphoreId_t done_sem; / / Complete notification semaphore void / / Target function pointer void / / Clean up callback function pointers arg; / / Function parameter bool in_use; / / TCB usage flag timeout_task_ctrl_block_t; timeout_task_ctrl_block_t g_tcb_array[MAX_TCB_NUM] = {0}.
[0044] Specifically, the caller task ID, delegate task ID, task semaphore ID, completion semaphore ID, and function parameters are all initialized to 0, while the target function pointer and cleanup callback function pointer are both initialized to null pointers.
[0045] Furthermore, the delegated task is executed in the following manner: the caller task wakes up the delegated task in a waiting state by releasing the task semaphore stored in the TCB. After the delegated task is woken up, it reads the target function pointer and parameters from the TCB and executes the target function. After the target function is executed, it releases the corresponding completion semaphore in the TCB to notify the caller that the task has been completed.
[0046] Specifically, the target function is user-defined. The target function pointer is passed to the TCB through a secure call interface. After the delegated task is awakened, it reads the target function pointer from the TCB and executes the target function through the pointer.
[0047] Furthermore, the normal execution of the delegated task includes: if the caller task acquires a completion semaphore within a preset timeout period, then a successful execution result is returned.
[0048] Furthermore, this embodiment solves the resource leaks and state inconsistencies caused by forced task termination by introducing a user-customizable cleanup callback function mechanism. When a function execution timeout is detected, the system does not rudely delete the task, but first executes the user-defined cleanup function to ensure that critical resources such as mutexes, double semaphores, dynamic memory, and hardware peripheral states are correctly released and restored, fundamentally avoiding system cascading failures caused by resource leaks.
[0049] Especially in safety-critical systems such as UAV flight control, it can ensure that even if a sensor reading function or control algorithm function times out, it will not affect the normal operation of other critical tasks (such as attitude stabilization and motor control), thus greatly improving the overall reliability and safety of the system.
[0050] The security cleanup mechanism includes the following: if the caller task fails to acquire the completion semaphore within a preset timeout period, then: the caller task first suspends the delegated task, then executes the cleanup callback function to release the resources occupied by the target function, restore the system state, terminate the delegated task, delete the dual semaphores, reset the corresponding TCB to an unused state, and return a timeout error.
[0051] Specifically, users need to customize a corresponding cleanup callback function based on the business characteristics of the target function, ensuring that the parameters of the cleanup callback function are consistent with those of the target function. The cleanup callback function pointer is then passed to the TCB and associated with the target function via a secure API call. When the target function times out, the caller task reads the cleanup callback function pointer from the TCB and triggers the cleanup callback function using this pointer. If the target function executes normally without timing out, the cleanup callback function pointer will be null.
[0052] Furthermore, the cleanup callback function is customized by the user according to the characteristics of the target function, and includes at least one of the following resource processing logics: releasing the mutex lock occupied by the target function, reclaiming dynamically allocated memory space, resetting the state of hardware peripherals, and clearing the data buffer.
[0053] Furthermore, the maximum number of TCBs in the TCB array is configured through a macro definition. Users can adjust the value of this macro definition according to the resource constraints and concurrency requirements of the RTOS system, and can easily adjust the number of concurrent timeout calls supported by the system to support different numbers of concurrent timeout calls, adapting to the resource constraints and performance requirements of different application scenarios.
[0054] This invention employs dual semaphores, including a task semaphore and a completion semaphore, to synchronize the caller's task information with the delegated task, thus avoiding race conditions. It also adopts a safe cleanup mechanism of suspending, cleaning up, and deleting to ensure that all necessary state recovery operations are completed before resources are released.
[0055] This invention, through innovative architecture design and security mechanisms, enables precise monitoring and control of the execution time of individual specific functions, achieving fine-grained control from "system-level reset" to "function-level management." It solves the long-standing problem of timeout control in embedded real-time systems, bringing significant improvements in security, real-time performance, resource efficiency, and availability. It has high practical value and broad application prospects.
[0056] Another specific embodiment of the present invention discloses a timeout control system with a safe cleanup mechanism for an RTOS.
[0057] This system provides developers with a clear error handling path. Functions return explicit statuses for both successful and timeout execution, and cleanup after timeouts is handled automatically by the system, reducing the developer's workload. This system can be applied to any RTOS-based embedded system, and is particularly suitable for fields with extremely high reliability requirements, such as UAV flight control, industrial control, and automotive electronics. The flowcharts for the operation of each module are shown below. Figure 2 , Figure 3 and Figure 4 As shown, it specifically includes: TCB Acquisition Module: Acquires the caller's task ID through a preset secure call interface, and searches for the corresponding TCB in the Task Control Block (TCB) array based on the caller's task ID; The delegated task execution module checks whether a delegated task has been created in the obtained TCB. If not, a new delegated task is created and executed according to the caller's task priority. If a delegated task has been created, the existing delegated task is reused and executed. After the delegated task is executed normally, the task control block TCB remains unused, and the delegated task in the task control block TCB returns to the waiting state for the caller to reuse. The timeout control module is used to complete the timeout control by employing a safety cleanup mechanism when a delegated task times out.
[0058] The working principle of the system is the same as that in the method embodiment, and will not be repeated here.
[0059] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.
[0060] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.
Claims
1. A timeout control method with a safe cleanup mechanism for RTOS, characterized in that, The method includes the following steps: Obtain the caller's task ID through a pre-defined secure API; The corresponding TCB is found in the Task Control Block (TCB) array based on the caller's task ID. Check whether a delegated task has been created in the obtained TCB. If not, create a new delegated task according to the caller's task priority and execute it; if it has been created, reuse the existing delegated task and execute it directly. After the delegated task is executed normally, the TCB is marked as unused, and the delegated task of the TCB is marked as waiting for the caller to reuse it. If the delegated task times out, a security cleanup mechanism will be used to complete the timeout control.
2. The timeout control method with a security cleanup mechanism for RTOS according to claim 1, characterized in that, The step of searching for the corresponding TCB in the Task Control Block (TCB) array based on the caller task ID includes: first, checking if there is a TCB that is already bound to the caller task ID; if there is, directly acquiring the TCB for reuse; if there is not, searching for the first unused TCB in the array, marking the unused TCB as used, and binding it to the caller task ID.
3. The timeout control method with a security cleanup mechanism for RTOS according to claim 1, characterized in that, The delegated task includes two semaphores; the two semaphores include a task semaphore and a completion semaphore; the priority of the delegated task is the same as the priority of its corresponding caller task.
4. The timeout control method with a safe cleanup mechanism for RTOS according to claim 1, characterized in that, The TCB structure stores: the caller task ID, the delegate task ID, the task semaphore ID, the completion semaphore ID, the target function pointer, the cleanup callback function pointer, function parameters, and usage status flags.
5. The timeout control method with a safety cleanup mechanism for RTOS according to claim 3, characterized in that, The delegated task is executed in the following manner: the caller task wakes up the delegated task in a waiting state by releasing the task semaphore stored in the TCB. After the delegated task is woken up, it reads the target function pointer and parameters from the TCB and executes the target function. After the target function is executed, it releases the corresponding completion semaphore in the TCB to notify the caller that the task has been completed.
6. The timeout control method with a security cleanup mechanism for RTOS according to claim 5, characterized in that, The normal execution of the delegated task includes: if the caller task acquires the completion semaphore within the preset timeout period, then a successful execution result is returned.
7. The timeout control method with a security cleanup mechanism for RTOS according to claim 1, characterized in that, The security cleanup mechanism includes: If the caller task fails to acquire the completion semaphore within the preset timeout period, then: the caller task first suspends the delegated task, then executes the cleanup callback function to release the resources occupied by the target function, restore the system state, terminate the delegated task, delete the dual semaphores, reset the corresponding TCB to an unused state, and return a timeout error.
8. The timeout control system with a safety cleanup mechanism for an RTOS according to claim 7, characterized in that, The cleanup callback function is customized by the user according to the characteristics of the target function, and includes at least one of the following resource processing logics: releasing the mutex lock occupied by the target function, reclaiming dynamically allocated memory space, resetting the state of hardware peripherals, and clearing the data buffer.
9. A timeout control system with a safety cleanup mechanism for an RTOS according to any one of claims 1-8, characterized in that, The maximum number of TCBs in the TCB array is configured through a macro definition. Users can adjust the value of this macro definition according to the resource constraints and concurrency requirements of the RTOS system to support different numbers of concurrent timeout calls.
10. A timeout control system with a safety cleanup mechanism for an RTOS, characterized in that, include: TCB Acquisition Module: Acquires the caller's task ID through a preset secure call interface, and searches for the corresponding TCB in the Task Control Block (TCB) array based on the caller's task ID; The delegated task execution module checks whether a delegated task has been created in the obtained TCB. If not, a new delegated task is created and executed according to the caller's task priority. If a delegated task has been created, the existing delegated task is reused and executed. After the delegated task is executed normally, the task control block TCB remains unused, and the delegated task in the task control block TCB returns to the waiting state for the caller to reuse. The timeout control module is used to complete the timeout control by employing a safety cleanup mechanism when a delegated task times out.