Task starvation prevention method and system

Abstract

This application provides a method and system for preventing task starvation. The method includes: acquiring a set of tasks in kernel mode that hold critical section resources awaiting high-priority tasks; performing execution flow truncation on the tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the core execution instruction for critical section release corresponding to the task, constructing the minimum kernel stack of the task, and modifying the program counter pointer and stack pointer of the task to interrupt the original execution flow of the task; and performing targeted release of critical section resources of the task after execution flow truncation based on the dynamic counting of the length of the critical section release instruction. By separating the task execution flow from the resource release operation, this application enables low-priority tasks to release critical section resources without being dependent on the advancement of their own complete business logic, thus achieving batch release of resources for multiple low-priority tasks holding different critical section resources.

Description

Technical Field

[0001] This application belongs to the field of task resource scheduling, and in particular relates to a method and system for preventing task starvation. Background Technology

[0002] In a multi-task hybrid scheduling environment, when a high-priority task waits for critical section resources held by a low-priority task, a priority inheritance mechanism is typically used to temporarily increase the priority of the low-priority task so that it can execute and release resources as quickly as possible. However, before releasing resources, low-priority tasks must sequentially execute complete kernel-mode business logic, system call returns, and user-mode address space switching. These operations, unrelated to resource release, consume scheduling cycles. If a high-priority task is simultaneously waiting for different critical section resources held by multiple low-priority tasks, each low-priority task must be scheduled and execute its original process sequentially. The cumulative execution time of multiple tasks can easily exceed a single scheduling cycle, and they may be allocated to different processor cores, crowding out the core resources available to the high-priority task. Conventional optimization schemes cannot complete the batch release of low-priority tasks holding multiple resources within a single scheduling cycle of a single processor core. Summary of the Invention

[0003] This application provides a task starvation protection method and system to achieve batch release of resources for multiple low-priority tasks holding different critical section resources, under the condition of allocating processor time in a single scheduling cycle and using a single processor core.

[0004] This application discloses a method for preventing task starvation, including: A set of tasks that are in kernel mode and hold critical section resources that are waiting for high-priority tasks; The execution flow is truncated for tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the critical section release core execution instruction corresponding to the task, constructing the minimum kernel stack of the task, modifying the program counter pointer of the task to the address of the critical section release core execution instruction, and modifying the stack pointer of the task to the starting address of the minimum kernel stack, so as to interrupt the original execution flow of the task. The dynamic counting of the length of the critical section release instruction includes counting the instruction length of the critical section release function in the kernel symbol table to determine the address of the critical section release core execution instruction. Based on the dynamic counting of the critical section release instruction length, the critical section resources of the task after the execution flow truncation process is released in a targeted manner.

[0005] Optionally, the execution flow truncation process for the tasks in the task set may also include saving the original hardware context of each task in the task set.

[0006] Optionally, saving the original hardware context of each task in the task set includes: Call the kernel register snapshot interface to obtain the task's program counter pointer, stack pointer, and general-purpose register data; The acquired raw hardware context is stored in the kernel register structure corresponding to the task.

[0007] Optionally, building the minimum kernel stack for the task includes reusing the free area of ​​the task's original kernel stack to store critical section resource handles in order to build the minimum kernel stack.

[0008] Optionally, the free area of ​​the original kernel stack of the task can be reused to store critical section resource handles to construct a minimal kernel stack, including: Determine the starting address of the unused free region in the original kernel stack of the task; Write the critical section resource handle into the free area, where the critical section resource handle is the kernel address that identifies the critical section resource to be released; The starting address of the free region is used as the starting address of the minimum kernel stack.

[0009] Optionally, after the critical section resources of the task are released in a targeted manner following the completion of the execution flow truncation process, the method further includes: Set the task that has completed resource release to an uninterruptible blocked state; Restore the original hardware context of the task to restore the original execution flow of the task.

[0010] Optionally, the task that has completed resource release can be set to an uninterruptible blocked state, including: Modify the process control block status bit of the task to the value corresponding to the uninterruptible blocked state; Remove the task from the processor core's local run queue.

[0011] Optionally, the original hardware context of the task is restored to restore the original execution flow of the task, including: Write back the stored raw hardware context to the kernel register structure corresponding to the task; Restore the task's program counter pointer and stack pointer to their original values ​​before the execution flow was truncated.

[0012] Optionally, the targeted release of critical section resources for tasks after execution flow truncation includes: Add the tasks in the task set to the local execution queue of the current processor core in batches; By using zero-overhead context switching, the critical sections of tasks executed serially on the current processor core are released, where the core execution instructions are released. The zero-overhead context switching is a switching method that only restores the program counter pointer and stack pointer of the task without loading the full hardware context.

[0013] Another aspect of this application discloses a task starvation prevention system, including a task screening unit, an execution flow truncation unit, and a resource-directed release unit; The task filtering unit is used to obtain a set of tasks that are in kernel mode and hold critical section resources waiting for high-priority tasks; The execution flow truncation unit is used to perform execution flow truncation processing on tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the critical section release core execution instruction corresponding to the task, constructing the minimum kernel stack of the task, modifying the program counter pointer of the task to the address of the critical section release core execution instruction, and modifying the stack pointer of the task to the starting address of the minimum kernel stack, so as to interrupt the original execution flow of the task. The dynamic counting of the length of the critical section release instruction includes counting the instruction length of the critical section release function in the kernel symbol table to determine the address of the critical section release core execution instruction. The resource-directed release unit is used to dynamically count based on the length of the critical section release instruction to complete the critical section resource-directed release of the task after the execution flow is truncated.

[0014] As can be seen from the above technical solution, the task starvation prevention method and system provided in this application separates the task execution flow from the resource release operation, so that the process of low-priority tasks releasing critical section resources is no longer dependent on the advancement of their own complete business logic. In the execution flow truncation process, the entry address and instruction length information of the critical section release function are obtained with the help of the kernel symbol table, and the address of the critical section release core execution instruction that skips the pre-stack frame and parameter verification operation is located, avoiding the repeated execution of irrelevant instruction segments on the release path. The free area of ​​the original kernel stack of the task is reused to write the handle of the resource to be released to form a minimal kernel stack, which can ensure that the release instruction correctly obtains the operation object without the need for new memory allocation. After modifying the program counter pointer and stack pointer to the above addresses respectively, when the task is scheduled, it only needs to complete the execution of the release instruction sequence, and the duration of a single release is limited to a very small range. Multiple tasks that have been truncated in the same way are added to the local run queue of the current processor core and executed serially in sequence with zero-overhead context switching that only restores two pointers, and the cumulative value of the release duration of each task is controlled within a single scheduling cycle window. After the release is complete, the pre-saved original hardware context is written back to the register, allowing the task execution flow to seamlessly integrate with the original business logic. All of the above operations utilize the kernel's native register read / write, symbol table access, and queue operation interfaces, without altering the scheduling framework's data structure or relying on new hardware instructions. This compresses the time consumed by critical section release operations within constraints when high-priority tasks face multiple resource waits. This application, by allocating processor time within a single scheduling cycle and using a single processor core, can achieve batch resource release for multiple low-priority tasks holding different critical section resources. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of the task starvation protection method in the embodiments of this application; Figure 2 This is a flowchart illustrating the execution flow truncation process for tasks in the task set in this embodiment of the application. Figure 3 This is a flowchart illustrating how the original hardware context of each task in the task set is saved in an embodiment of this application. Figure 4 This is a flowchart of storing critical section resource handles in the free area of ​​the original kernel stack of the reused task in the embodiments of this application to construct a minimal kernel stack; Figure 5 This is a flowchart illustrating how a task that has completed resource release is set to an uninterruptible blocking state in an embodiment of this application. Figure 6 This is a flowchart illustrating how the original hardware context of the task is restored to recreate the original execution flow of the task in this embodiment of the application. Figure 7 This is a flowchart illustrating the directed release of critical section resources for a task after execution flow truncation processing, as described in this application embodiment. Figure 8 This is a structural diagram of the task starvation protection system in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In the system-level observation of the critical section resource waiting problem in a multi-task hybrid scheduling environment, it was found that in the operating system kernel that supports the concurrent execution of multiple priority tasks, when a high-priority task enters a blocked state because it tries to acquire a critical section resource that is already held by a low-priority task, the system scheduler needs to prompt the low-priority task holding the resource to release the resource as soon as possible so that the high-priority task can resume execution.

[0019] Currently, the solution to the priority inversion problem is the priority inheritance protocol, which temporarily elevates the execution priority of a low-priority task holding resources to the priority level of a blocked high-priority task. This allows the task to gain more processor time, accelerating its execution progress and reaching the resource release point sooner. The priority inheritance protocol has been implemented in various real-time operating systems. Its technical premise is to maintain the integrity of the original execution flow of the low-priority task, only changing the weight of the processor time slice obtained by the task through dynamic priority adjustment. However, after being scheduled, the task still needs to execute its original kernel-mode business instruction sequence, system call return instruction sequence, and user-mode address space switching instruction sequence one by one. These instruction segments, which have no direct causal relationship with the critical section resource release operation itself, together constitute the time consumption from scheduling to completion of the low-priority task's release.

[0020] When a high-priority task simultaneously waits for critical section resources held by multiple low-priority tasks, the priority inheritance protocol needs to process each low-priority task one by one. Each task, after gaining a promoted priority, executes its complete kernel-mode execution path. The cumulative processor time required by multiple tasks will span multiple scheduling cycles, and task migration may occur between different processor cores, crowding out scheduling resources of high-priority tasks on other cores. The root cause of the above problem is not entirely due to the quality of the priority allocation strategy, but rather that the business execution flow of low-priority tasks and the critical section resource release operation are bound to the same instruction sequence, meaning that the resource release action can only occur after the business logic has been completed. To overcome the time constraints of a single processor core and a single scheduling cycle, the business execution flow and resource release operation need to be separated at the instruction execution level, constructing independent execution units containing only the necessary instructions for resource release.

[0021] To address at least one of the problems existing in the prior art, this embodiment discloses a task starvation protection method, such as... Figure 1 As shown, the method includes the following steps: S100: A set of tasks that are in kernel mode and hold critical section resources that are waiting for high-priority tasks.

[0022] S200: Perform execution flow truncation processing on the tasks in the task set.

[0023] S300: Based on the dynamic counting of the length of the critical section release instruction, the critical section resources of the task after the execution flow truncation process are released in a targeted manner.

[0024] Specifically, the execution flow truncation process for the tasks in the task set includes determining the critical section of the task, releasing the address of the core execution instruction, constructing the minimum kernel stack of the task, and modifying the program counter pointer and stack pointer of the task. Further, such as... Figure 2 As shown, the execution flow truncation process for the tasks in the task set includes: S201: Determine the address of the critical section release core execution instruction corresponding to the task based on dynamic counting of the critical section release instruction length.

[0025] S202: Minimal kernel stack for building tasks.

[0026] S203: Modify the task's program counter pointer to the address of the critical section release kernel execution instruction and modify the task's stack pointer to the starting address of the minimum kernel stack.

[0027] This embodiment separates the execution flow of low-priority tasks from the critical section resource release operation. First, it acquires a set of tasks in kernel mode that hold critical section resources awaited by high-priority tasks, limiting the scope of processing. Then, it truncates the execution flow of each task within the set. This truncation is based on a dynamic counting mechanism of the critical section release instruction length. Specifically, it reads the entry address and instruction length of the critical section release function from the kernel symbol table to determine the address of the core execution instruction for critical section release after skipping pre-processing instructions such as stack frame preparation and parameter verification. Simultaneously, it constructs a minimal kernel stack for the task, containing only resource handles, and sets the program counter to the address of the core execution instruction and the stack pointer to the start address of the minimal kernel stack. When a truncated task is scheduled, it directly executes the release instruction without traversing its original business logic. Each task completes the targeted release serially within the same processor core's local queue. After release, the hardware context before truncation is restored, ensuring the task's business logic remains executable. All information throughout this process comes from existing kernel data structures and interfaces; no kernel source code is modified, and no new hardware is added.

[0028] Specifically, this embodiment introduces execution flow truncation processing into the critical section resource release process. The basic operation of execution flow truncation processing is to modify the task's program counter pointer and stack pointer, causing the task's instruction execution sequence to jump from the original business logic to a position containing only the core execution instruction for critical section release. To ensure the accuracy of this jump, this application further introduces dynamic counting processing for the length of the critical section release instruction. By pre-analyzing the instruction layout of the critical section release function in the kernel symbol table, the address of the core release instruction after skipping the pre-operations such as stack frame preparation and parameter verification at the function entry point is determined, and the program counter pointer is set to this address. At the same time, the unoccupied free area in the task's original kernel stack is reused, and the kernel address identifying the critical section resource to be released is written as a resource handle. A minimal kernel stack is constructed, and the stack pointer points to this area, providing an operand source for the release instruction. After the above processing, the task's instruction execution path is directed to directly start execution from the beginning of the core release instruction and obtain the pre-set resource handle in the stack to complete the release, without traversing the original business logic, system call return, and user mode switching instruction segments.

[0029] Existing scheduling optimization schemes adjust task priorities to allow lower-priority tasks to be scheduled faster or more frequently, but still rely on the execution logic of their own tasks to release resources. In contrast, this embodiment does not rely on the execution logic of the tasks themselves, but instead constructs a dedicated release instruction execution path that is independent of the main task logic by modifying the task execution context. This embodiment does not aim to speed up the overall task execution speed, but rather to eliminate instruction execution unrelated to release, thereby controlling the sum of the release times of multiple tasks within a single scheduling cycle. From an implementation perspective, constructing the aforementioned dedicated release execution path faces two operational obstacles: first, how to obtain the precise address of the core release instruction in the critical section release function; and second, how to construct the minimum stack environment required for the execution flow while ensuring the task can continue to run normally. This embodiment solves the first operational obstacle by reading the entry address of the release function from the kernel symbol table and adding it to the address value of the preceding instruction length. The preceding instruction length can be obtained using the instruction segment offset recorded in the kernel symbol table or a fixed offset value generated during compilation, without requiring runtime disassembly. The second operational obstacle is solved by detecting the used area of ​​the task's original kernel stack, writing the resource handle into the free area as the minimum kernel stack content, and modifying the stack pointer to point to that area. The minimum kernel stack only needs to carry a single resource handle, occupying no more than sixteen bytes, without affecting the integrity of the original stack data. Both operational obstacles are solved based on existing kernel data structures and operation interfaces, without requiring modification of the kernel source code or the addition of new hardware modules.

[0030] It should be noted that the operating environment used in this embodiment is an operating system kernel that supports multi-task scheduling. The kernel has basic capabilities for process management, register operations, symbol table reading, and scheduling queue management. All operations in this application are implemented based on the kernel's native interface, without any intrusive modifications to the kernel source code, and without adding any processor instructions or hardware modules. It is suitable for electronic devices containing a multi-core architecture of a central processing unit (CPU). Each CPU core of the electronic device has an independent local run queue, and the kernel can perform snapshot and write-back operations on the hardware context of tasks.

[0031] It should be noted that, in this embodiment, The task set defines the scope of the objects to be processed, including the task's running state and resource holding state. It excludes user-mode tasks, tasks that do not hold the resources being waited for, and tasks whose resources are not being waited for by higher-priority tasks. Here, "higher priority" in "high-priority task waiting" can be understood to mean that the waiting task has a higher priority than the tasks in the set. Specifically, the task set consists of tasks in kernel mode that hold critical section resources that higher-priority tasks are waiting for. Kernel mode is the state in which tasks run in the kernel privilege space, where they can access kernel resources and execute kernel instructions. The critical section resources that higher-priority tasks are waiting for are synchronization resources that have caused higher-priority tasks to enter a blocked state due to their inability to acquire them, including kernel synchronization objects such as spinlocks, mutexes, and semaphores. The task set filtering process is implemented based on the kernel's native resource management module and task status detection module. The kernel resource management module maintains a mapping relationship between critical section resources and their holder tasks, and can directly read the holding tasks corresponding to each critical section resource. The task status detection module can obtain the running status of each task and determine whether the task is in kernel mode and can be interrupted. The waiting queue of high-priority tasks stores information on the critical section resources that the tasks are waiting for. By matching the data of the three, tasks that meet the conditions are filtered out. The execution overhead of the filtering process is within the kernel's acceptable range.

[0032] Execution flow truncation involves modifying the program counter pointer and stack pointer of a task to interrupt its original execution flow. The program counter pointer is a register in the CPU that stores the address of the next instruction to be executed, and the stack pointer is a register in the CPU that stores the current address of the task's kernel stack. Modifying the values ​​of these two registers changes the instruction execution sequence of the task, causing the task to jump to the specified instruction address for execution. This process is implemented through the kernel's native register operation interface, without altering the data in the task's process control block except for the register image. It only interrupts the original execution flow of the task without disrupting its running state. The modification operation is only performed when the task is in kernel mode and interruptible, avoiding triggering kernel runtime exceptions. Execution flow truncation achieves targeted jumps in the task's execution flow by modifying the values ​​of these two registers, without modifying the task's memory mapping, signal states, file descriptors, or other data. It does not have an irreversible impact on the normal operation of the task. At the same time, it can skip redundant instruction segments such as business logic, system calls, and user-mode returns in the original execution flow of the task, retaining only the instruction sequence required for releasing critical section resources, compressing the task's execution time, and providing time conditions for multiple tasks to complete batch releases within the same scheduling cycle.

[0033] The dynamic counting of critical section release instruction lengths involves counting the instruction lengths of critical section release functions in the kernel symbol table to determine the address of the core execution instruction for critical section release. The kernel symbol table is a function address mapping table generated during the kernel compilation stage. The table stores the entry virtual address, instruction length, and function name of each kernel function. It can be obtained directly by reading without disassembly or dynamic parsing. The address of the core execution instruction for critical section release is the address corresponding to the instruction in the critical section release function that completes the resource release operation. It does not include pre-instructions such as function stack frame preparation and parameter verification. The counting process only involves reading the kernel symbol table and numerical calculation, and the execution overhead is negligible.

[0034] In an optional implementation, the execution flow truncation process for the tasks in the task set further includes saving the original hardware context of each task in the task set.

[0035] Specifically, saving the original hardware context of each task in the task set yields hardware context snapshot data for the tasks. This snapshot data is used to restore the task's execution flow to its pre-truncation state after resource release. For example, saving the original hardware context of each task in the task set is executed before determining the address of the critical section release core execution instruction corresponding to the task based on a dynamic count of the critical section release instruction length.

[0036] In alternative implementations, such as Figure 3 As shown, storing the original hardware context of each task in the task set includes: S2001: Call the kernel register snapshot interface to obtain the task's program counter pointer, stack pointer, and general-purpose register data.

[0037] S2002: Store the acquired raw hardware context into the kernel register structure corresponding to the task.

[0038] In this embodiment, the acquired raw hardware context is stored in the kernel register structure corresponding to the task, resulting in a snapshot of the stored hardware context. The kernel register snapshot interface is a register operation interface natively provided by the kernel, corresponding to the pt_regs structure in the kernel. This structure can store all hardware register data of the CPU, including the program counter pointer, stack pointer, and general-purpose register data. The program counter pointer is used to store the address of the next instruction to be executed in the task, the stack pointer is used to store the current address of the task's kernel stack, and the general-purpose registers are used to store temporary data during task execution. Calling this interface allows direct reading of all current hardware register values ​​of the task without additional parsing and calculation. Storing the acquired raw hardware context in the kernel register structure corresponding to the task is a fixed data structure allocated by the kernel for each task, corresponding one-to-one with the task's process control block. The storage location is in the kernel's dedicated memory space and will not be modified by the task's execution flow, ensuring the integrity and security of the snapshot data. Restoring the subsequent task execution flow only requires writing the data in the structure back to the hardware registers.

[0039] For example, taking an x86 architecture electronic device as an example, when a task is in kernel mode, the kernel can read the value of the RIP register (the task's program counter pointer) and the value of the RSP register (the task's stack pointer) through the pt_regs interface. Simultaneously, it reads the values ​​of general-purpose registers such as RAX, RBX, RCX, and RDX, storing all values ​​in the corresponding pt_regs structure. This completes a snapshot of the hardware context. This operation only involves reading and storing register data, and the execution overhead is within the kernel's acceptable range. The complete preservation of the hardware context provides the data foundation for restoring the subsequent task execution flow. Only by completely preserving all register data before the task execution flow was truncated can the task's execution flow be restored to its pre-truncation state after resource release, allowing the task to continue executing its original business logic without data loss or process interruption.

[0040] In an optional implementation, building the minimum kernel stack for the task includes reusing the free area of ​​the task's original kernel stack to store critical section resource handles in order to build the minimum kernel stack.

[0041] The original kernel stack of the task is a dedicated stack space allocated by the kernel for the task. This stack space contains unused free areas. Reusing these free areas to store critical section resource handles eliminates the need to allocate new stack memory for the task, thus avoiding memory allocation and deallocation overhead and stack overflow issues. The critical section resource handle is the kernel address that identifies the critical section resource and serves as the input parameter for the critical section release function. After storing this handle, the release function can directly obtain the address of the target resource to complete the resource release operation. The minimum kernel stack size only needs to store the critical section resource handle, occupying no more than sixteen bytes of stack space, far smaller than the original kernel stack size of the task. This avoids occupying the used space of the original kernel stack and does not corrupt the data within the original task stack. After the task execution flow is restored, the contents of the original kernel stack remain completely unchanged.

[0042] After modifying the task's stack pointer to the starting address of the minimum kernel stack, the task can directly obtain the critical section resource handle from the stack when executing the release instruction, without accessing the original kernel stack contents. This ensures the normal execution of the release function. The stack pointer modification operation is completed through the kernel register interface, modifying only the register values ​​and not altering the stack space's storage contents. After modifying the task's program counter pointer to the address of the critical section release kernel execution instruction, the task's next execution instruction will be the resource release instruction. This achieves a directed jump in the execution flow; the task will directly execute the resource release operation without executing any instruction segments from the original execution flow.

[0043] In alternative implementations, such as Figure 4 As shown, the free area of ​​the original kernel stack of the reused task stores the critical section resource handles to construct a minimal kernel stack, including: S2021: Determine the starting address of the unused free area in the original kernel stack of the task.

[0044] S2022: Write the critical section resource handle to the free area, where the critical section resource handle is the kernel address that identifies the critical section resource to be released.

[0045] S2023: Use the starting address of the free region as the starting address of the minimum kernel stack.

[0046] The process involves determining the starting address of an unused free region in the original kernel stack of the task. This is achieved by reading the address difference between the kernel stack start address recorded in the task's process control block and the current stack pointer. The range of the used region is obtained, and the stack space outside the used region is the free region. The starting address of the free region is the address of the last used region, rounded up according to the processor stack alignment requirements. The critical section resource handle is written to this free region. The critical section resource handle is the kernel address that identifies the critical section resource to be released. This address is generated by the kernel resource management module during resource allocation and recorded in the task's resource holding information. It can be directly read, and the write operation is completed through a memory assignment instruction, with negligible execution overhead. Using the starting address of this free region as the starting address of the minimum kernel stack, and setting the stack pointer to this address, the correct resource handle can be read from the stack when the release function is executed.

[0047] For example, the end address of the used area of ​​the original kernel stack of the task is a certain hexadecimal address. After rounding up according to the stack alignment requirements, the starting address of the free area is obtained. The critical section resource handle is written to this starting address to build a minimal kernel stack. This minimal kernel stack contains only one storage unit, namely the resource handle, and occupies no more than sixteen bytes of space. The used data of the original kernel stack of the task is completely unaffected. After the task execution flow is restored, the original stack content remains intact.

[0048] In an optional implementation, after the critical section resources of the task are released following the execution flow truncation process, the method further includes: Set the task that has completed resource release to an uninterruptible blocked state; Restore the original hardware context of the task to restore the original execution flow of the task.

[0049] Specifically, setting a task that has completed resource release to an uninterruptible blocked state aims to prevent the task from being rescheduled before the execution flow is restored, thus preventing damage to the execution context. The uninterruptible blocked state is characterized by the task not responding to any scheduling signals other than kernel wake-up operations; the task remains blocked until the subsequent flow restoration operation is completed. Restoring the task's original hardware context restores the original execution flow by rewriting the previously saved hardware context snapshot data into the task's corresponding hardware registers, returning the task's execution flow to its position before truncation. The task can then continue executing its original business logic.

[0050] In alternative implementations, such as Figure 5 As shown, setting a task that has completed resource release to an uninterruptible blocked state includes: S4011: Modify the process control block status bit of the task to the value corresponding to the uninterruptible blocked state.

[0051] S4012: Remove the task from the local run queue of the processor core.

[0052] The process control block (PCB) is a data structure in the kernel that stores task execution information. The status bits are fields in the PCB that identify the task's running status. The status bit values ​​corresponding to the uninterruptible blocked state are fixed kernel-defined values. Modification operations only require assigning values ​​to the status bits; no other data in the PCB needs to be changed, resulting in low execution overhead. Removing a task from the processor core's local run queue is done through the kernel's native queue deletion interface. After removal, the scheduler will not re-enable the task to the current processor core, preventing the task from being scheduled and executing instructions from the original flow before the flow is restored.

[0053] In alternative implementations, such as Figure 6 As shown, restoring the original hardware context of the task to restore the original execution flow of the task includes: S4021: Write back the stored raw hardware context to the kernel register structure corresponding to the task.

[0054] S4022: Restore the task's program counter pointer and stack pointer to their original values ​​before the execution flow was truncated.

[0055] The hardware context write-back operation corresponds to the save operation. It rewrites the data stored in the kernel register structure back into the hardware registers corresponding to the task. After the program counter pointer and stack pointer are restored to their original values, the task's execution flow returns to the position before the execution flow was truncated. After the general-purpose register data is restored, the task's temporary running data remains intact, and the task can continue to execute its original business logic without any execution flow interruption or data loss issues. After the write-back is completed, the task's running state is the same as before the execution flow was truncated, and the task is unaware that its execution flow has been modified.

[0056] In alternative implementations, such as Figure 7 As shown, the targeted release of critical section resources for a task after execution flow truncation includes: S301: Add the tasks in the task set to the local execution queue of the current processor core in batches.

[0057] S302: By using zero-overhead context switching, the critical sections of the tasks executed serially on the current processor core are released to release the core execution instructions. The zero-overhead context switching is a switching method that only restores the program counter pointer and stack pointer of the task without loading the full hardware context.

[0058] This method involves batch adding tasks from the task set to the local run queue of the current processor core. This batch addition operation is performed through the kernel queue batch insertion interface, eliminating the need to add tasks individually and reducing queue operation overhead. Since all tasks are added to the local run queue of the current processor core, cross-core task migration is not triggered, and the computing resources of other processor cores are not consumed. The scheduling permissions of high-priority tasks on other processor cores remain unaffected. Zero-overhead context switching is used to serially execute the critical sections of each task on the current processor core, releasing the core execution instructions. Zero-overhead context switching restores only the task's program counter pointer and stack pointer without loading the full hardware context. Conventional context switching requires saving the entire register state of the current task and loading the entire register state of the next task, including general-purpose registers, floating-point registers, and control registers. The switching overhead is typically on the order of microseconds, while zero-overhead context switching only requires assigning values ​​to two registers, reducing the switching overhead to the order of two register write operations, which is negligible. By executing tasks serially on the current processor core, all release operations are completed within a single scheduling cycle, without spanning multiple scheduling cycles, thus meeting time constraints. The serial execution method avoids resource contention issues that may arise from parallel release of multiple tasks.

[0059] This application also provides a task starvation protection system, such as Figure 8 As shown, it includes a task filtering unit 11, an execution flow truncation unit 12, and a resource-directed release unit 13; The task filtering unit 11 is used to obtain a set of tasks that are in kernel mode and hold critical section resources waiting for high-priority tasks. The execution flow truncation unit 12 is used to perform execution flow truncation processing on the tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the critical section release core execution instruction corresponding to the task, constructing the minimum kernel stack of the task, modifying the program counter pointer of the task to the address of the critical section release core execution instruction, and modifying the stack pointer of the task to the starting address of the minimum kernel stack, so as to interrupt the original execution flow of the task. The dynamic counting of the length of the critical section release instruction includes counting the instruction length of the critical section release function in the kernel symbol table to determine the address of the critical section release core execution instruction. The resource-directed release unit 13 is used to dynamically count based on the length of the critical section release instruction to complete the critical section resource-directed release of the task after the execution flow is truncated.

[0060] The technical effects of the task starvation protection system provided in this application are consistent with the corresponding methods, and will not be elaborated here.

[0061] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0062] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for task starvation prevention, the method comprising: include: A set of tasks that are in kernel mode and hold critical section resources that are waiting for high-priority tasks; The execution flow is truncated for tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the critical section release core execution instruction corresponding to the task, constructing the minimum kernel stack of the task, modifying the program counter pointer of the task to the address of the critical section release core execution instruction, and modifying the stack pointer of the task to the starting address of the minimum kernel stack, so as to interrupt the original execution flow of the task. The dynamic counting of the length of the critical section release instruction includes counting the instruction length of the critical section release function in the kernel symbol table to determine the address of the critical section release core execution instruction. Based on the dynamic counting of the critical section release instruction length, the critical section resources of the task after the execution flow truncation process is completed are released in a targeted manner to achieve task starvation protection.

2. The method of claim 1, wherein, The execution flow truncation process for the tasks in the task set also includes saving the original hardware context of each task in the task set.

3. The method according to claim 2, characterized in that, Saving the original hardware context of each task in the task set includes: Call the kernel register snapshot interface to obtain the task's program counter pointer, stack pointer, and general-purpose register data; The acquired raw hardware context is stored in the kernel register structure corresponding to the task.

4. The method according to claim 1, characterized in that, Building the minimum kernel stack for a task involves reusing the free areas of the task's original kernel stack to store critical section resource handles in order to build the minimum kernel stack.

5. The method according to claim 4, characterized in that, The free area of ​​the original kernel stack of the task is reused to store critical section resource handles in order to build a minimal kernel stack, including: Determine the starting address of the unused free region in the original kernel stack of the task; Write the critical section resource handle into the free area, where the critical section resource handle is the kernel address that identifies the critical section resource to be released; The starting address of the free region is used as the starting address of the minimum kernel stack.

6. The method according to claim 1, characterized in that, After the critical section resources of the task are released in a targeted manner following the completion of the execution flow truncation process, the method further includes: Set the task that has completed resource release to an uninterruptible blocked state; Restore the original hardware context of the task to restore the original execution flow of the task.

7. The method according to claim 6, characterized in that, Set tasks that have completed resource release to an uninterruptible blocked state, including: Modify the process control block status bit of the task to the value corresponding to the uninterruptible blocked state; Remove the task from the processor core's local run queue.

8. The method according to claim 6, characterized in that, Restore the original hardware context of the task to restore the original execution flow of the task, including: Write back the stored raw hardware context to the kernel register structure corresponding to the task; Restore the task's program counter pointer and stack pointer to their original values ​​before the execution flow was truncated.

9. The method according to claim 1, characterized in that, The targeted release of critical section resources for tasks after execution flow truncation includes: Add the tasks in the task set to the local execution queue of the current processor core in batches; By using zero-overhead context switching, the critical sections of tasks executed serially on the current processor core are released, where the core execution instructions are released. The zero-overhead context switching is a switching method that only restores the program counter pointer and stack pointer of the task without loading the full hardware context.

10. A task starvation protection system, characterized in that, It includes a task filtering unit, an execution flow truncation unit, and a resource-directed release unit; The task filtering unit is used to obtain a set of tasks that are in kernel mode and hold critical section resources waiting for high-priority tasks; The execution flow truncation unit is used to perform execution flow truncation processing on tasks in the task set, including: dynamically counting based on the length of the critical section release instruction, determining the address of the critical section release core execution instruction corresponding to the task, constructing the minimum kernel stack of the task, modifying the program counter pointer of the task to the address of the critical section release core execution instruction, and modifying the stack pointer of the task to the starting address of the minimum kernel stack, so as to interrupt the original execution flow of the task. The dynamic counting of the length of the critical section release instruction includes counting the instruction length of the critical section release function in the kernel symbol table to determine the address of the critical section release core execution instruction. The resource-directed release unit is used to dynamically count based on the length of the critical section release instruction to complete the critical section resource-directed release of the task after the execution flow is truncated.

Images