A task control method, apparatus, device, and medium

Abstract

The task control method, device, equipment and medium provided by the embodiment of the application have the following beneficial effects: an independent memory area is allocated for a task; when the task runs, data access is controlled to be executed with limited permissions, and instruction execution is controlled to be executed with high-privilege permissions; the limited permissions are released at the kernel entry, and the limited permissions are restored at the kernel exit; when tasks interact with each other, kernel functions are called or shared resource areas are reserved to read and write messages; in an exception processing stack, exception information is recorded and a state is marked; a faulty task is isolated, and a normal task is executed simultaneously; based on the exception information, the faulty task is restarted, degraded or deleted, and resources are released. By constraining the memory access behavior of a task, in combination with an exception capturing, scheduling cooperation and resource recovery mechanism, the isolation and online recovery of a task-level fault are realized, high-fineness and high-precision task control is realized, system crashes caused by a single task exception are effectively avoided, and the reliability of an operating system is improved.

Description

Technical Field

[0001] This invention relates to the field of computer operating system technology, and more specifically to a task control method, apparatus, device, and medium. Background Technology

[0002] In a real-time operating system (RTOS), multiple tasks typically run at the same privilege level and share memory space. Illegal access within a task (such as out-of-bounds access or dangling pointers) can lead to kernel data corruption or other task errors, thereby causing a system crash.

[0003] In RTOS, task management is based on Memory Protection Units (MPUs) or watchdog timers, but these methods have the following shortcomings: due to the limited number of resources and granularity, memory protection mechanisms are difficult to achieve fine-grained isolation in multi-tasking environments; when a task fails, a system-level reset is triggered, making it impossible to isolate and recover from individual task failures; there is a lack of control over the propagation of task failures, which can easily spread to the entire system once an failure occurs, and there is a lack of fine-grained recovery mechanisms for different failure types.

[0004] Therefore, it is necessary to provide a method for achieving task-level isolation and exception recovery in a user-space-free environment.

[0005] As can be seen from the above description, the task control in current operating systems has low granularity and poor precision. How to improve the granularity and precision of task management and thus ensure the reliability of the entire operating system is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] To overcome the shortcomings of existing task control methods, such as low granularity and poor precision, which leads to poor operating system reliability, this invention proposes a task control method, apparatus, device, and medium.

[0007] To achieve the above objectives, according to a first aspect of the present invention, an embodiment of the present invention provides a task control method, the method comprising the following steps: Each task has its own independent memory region allocated in memory. During task execution, the access control bits in the status register are configured to control data access to be executed with restricted privileges to access its independent memory region, and instruction execution to be executed with high privileges to access the entire memory domain. If a kernel function is called, the restricted privileges are removed by clearing the access control bits at the kernel entry point, and the restricted privileges are restored by resetting the access control bits at the kernel exit point. When interacting with other tasks, kernel functions are called to read and write messages from the message queue, or the corresponding task is dynamically configured to read and write permissions to the reserved shared resource area in memory to read and write messages. In response to task exceptions, exception information is recorded in a separate exception handling stack, and the task status is marked as a fault state. Disabling interrupts or using atomic operations can isolate tasks in a faulty state while scheduling tasks in a normal state for execution. Based on the anomaly information, perform one of the following operations on the faulty task: restart, downgrade, or delete and release resources.

[0008] Optionally, allocating an independent memory region for each task in the memory includes allocating its independent memory region upwards according to the memory requirements of each task; if the independent memory region is larger than the memory requirements, the independent memory region exceeding the memory requirements is configured as a protected region to prevent out-of-bounds access.

[0009] Optionally, restoring restricted privileges at the kernel exit by resetting its access control bits includes counting the number of nestings by a nesting identifier during the kernel function call. The number of nestings is accumulated when nesting and decremented when exiting the nest. When the nesting identifier is zero, the restricted privileges are restored at the kernel exit by resetting its access control bits.

[0010] Optionally, the task of isolating the fault state includes any of the following operations: Remove tasks in a faulty state from the scheduling queue so that they are not subject to scheduling; Cancel access permissions of a failed task to its independent memory region; Mark the task in a faulty state as frozen and prevent it from executing.

[0011] Optionally, the step of performing any one of the following operations on a task in a faulty state based on anomaly information: restart, downgrade, or delete and release resources: If a task is considered important and the number of failures within a preset time window is less than a first threshold, a restart operation will be performed to allow the task to run again. When the number of times a task fails within a preset time window exceeds the first threshold, or when a task directly accesses the corresponding memory region of the kernel, a deletion and resource release operation is performed to prevent it from running and reclaim the resources it occupies. When a task requests memory more frequently than the second threshold and fails to release the requested memory, or when processor utilization exceeds the third threshold, a demotion operation is performed to lower its priority.

[0012] Optionally, the method also includes performing any one of the following operations when all tasks are in a faulty state: idle task, system degradation, and recovery of the running core.

[0013] Optionally, when the first task sends data to the second task, during the inter-task interaction, kernel functions are invoked to read and write data from the message queue, including: The first task is to remove restricted permissions by calling the first kernel function, send the data to the message queue, and restore restricted permissions after the data is sent. The second task is to remove restricted permissions by calling the second kernel function, read data from the message queue, and restore restricted permissions after reading is complete. The dynamic configuration corresponds to the task's read and write permissions for the reserved shared resource area in memory, as well as read and write messages, including: Configure the first task to have write permissions to the reserved shared resource area, and write the data to the reserved shared resource area; Configure the second task to have read permissions for the reserved shared resource area, and read data from the reserved shared resource area.

[0014] According to a second aspect of the present invention, embodiments of the present invention also provide a task control device, comprising: The allocation module is used to allocate an independent memory region for each task in memory; The permissions module is used during task runtime to control data access to its independent memory region by configuring the access control bits in the status register, and instruction execution to the entire memory domain by executing with high privileges. If a kernel function is called, the restricted permissions are removed at the kernel entry point by clearing the access control bits, and the restricted permissions are restored at the kernel exit by resetting the access control bits. The interaction module is used to call kernel functions to read and write messages from the message queue when interacting between tasks, or to dynamically configure the corresponding task's read and write permissions for the reserved shared resource area in memory to read and write messages. The marking module is used to respond to task exceptions by recording exception information and marking the task status as a fault state in a separate exception handling stack. The isolation module is used to shield interrupts or use atomic operations to isolate tasks in a faulty state, while scheduling and executing tasks in a normal state. The exception handling module is used to perform any one of the following operations on a task in a faulty state based on exception information: restart, downgrade, or delete and release resources.

[0015] According to a third aspect of the present invention, embodiments of the present invention also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the task control method as described in any of the above embodiments.

[0016] According to a fourth aspect of the present invention, embodiments of the present invention also provide a storage medium storing at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the steps of the task control method as described in any of the above embodiments.

[0017] As described above, the task control method, apparatus, device, and medium provided by the embodiments of the present invention have the following beneficial effects: Each task has an independent memory region allocated in memory; during task execution, by configuring the access control bits of the status register, data access is controlled to execute with restricted privileges to access its independent memory region, and instruction execution is controlled to execute with high privileges to access the entire memory domain; if a kernel function is called, the restricted privileges are removed at the kernel entry point by clearing the access control bits, and the restricted privileges are restored at the kernel exit point by resetting the access control bits; during inter-task interaction, kernel functions are called to read and write messages from the message queue, or the corresponding task's read and write permissions for the reserved shared resource area in memory are dynamically configured to read and write messages; in response to task exceptions, exception information is recorded in an independent exception handling stack, and the task status is marked as a fault state; interrupts are masked or atomic operations are used to isolate tasks in the fault state, while tasks in the normal state are scheduled for execution; based on the exception information, any one of the following operations is performed on the tasks in the fault state: restart, downgrade, or delete and release resources. This invention isolates and recovers task-level faults in real-time operating systems based on processor memory access control mechanisms. By constraining memory access behavior during task execution and combining exception capture, scheduling coordination, and resource recovery mechanisms, it achieves task-level fault isolation and online recovery, thereby realizing high-granularity and high-precision task control, effectively preventing single task anomalies from causing the entire system to crash, and thus improving system reliability. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a task control method provided in an embodiment of the present invention; Figure 2 This is an overall block diagram of a task control system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a memory access model provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a task execution permission model provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an inter-task communication process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of an exception triggering and handling process provided by an embodiment of the present invention; Figure 7This is a schematic diagram of a task state switching provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a task control device provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the hardware structure of an electronic device for implementing the task control method provided in an embodiment of the present invention. Detailed Implementation

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

[0020] Please see Figures 1 to 9 It should be noted that the illustrations provided in this embodiment are only schematic representations of the basic concept of the present invention. Therefore, the illustrations only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0021] See Figure 1 This is a flowchart illustrating a task control method provided in an embodiment of the present invention, as shown below. Figure 1 As shown in the figure, this embodiment of the invention illustrates the flow of a task control method implemented by a task scheduler. It should also be noted that, in the description of the specific embodiments, this invention uses a real-time operating system with PMP (Physical Memory Protection) and MPRV (Modify Privilege) mechanisms in the RISC-V architecture as an example to provide a detailed explanation of the relevant steps. In this embodiment, the operating system adopts a scheduling model similar to FreeRTOS, but this invention is not limited to this specific implementation.

[0022] Step S101: Allocate an independent memory region for each task in memory.

[0023] To clearly illustrate the task control method of the present invention, the system architecture of the present invention will first be described in detail, see [link to relevant documentation]. Figure 2 This is a general block diagram of a task control system provided in an embodiment of the present invention, such as... Figure 2The diagram illustrates the runtime state of an operating system (RTOS). Specifically, multiple tasks, such as Task A, Task B, and Task N, are executed simultaneously within the operating system. When any task encounters an exception, a monitoring task (Supervisor Task) is triggered to handle the exception. Each Task has access to memory (RAM), and the memory address spaces of each Task are isolated from each other. Data interaction between Tasks is supported, as illustrated by calling IPC service functions (IPCService). It should be noted that implementing inter-task interaction via IPC is only one exemplary implementation of this invention; it can also be achieved by reserving a shared resource area in memory, which will be described in detail later. The task scheduler (Scheduler) manages task scheduling and schedules the execution of each Task.

[0024] Based on the above system architecture, this embodiment of the invention performs task initialization and memory isolation configuration, thereby allocating an independent memory region in memory for each task. In specific implementations, this independent memory region includes at least a task stack area and a task data area. Where permission control is required, it may also include a task code area. The task stack area is used to store local variables, function call information, CPU register context, etc.; the task data area is used to store data required for task execution; and the task code area stores the task execution code. The kernel itself uses an independent global memory region, isolated from the independent memory regions used by the tasks. See also... Figure 3 This is a schematic diagram of a memory access model provided in an embodiment of the present invention, such as... Figure 3 This illustrates the memory partitioning (isolation) status. The entire RAM space is divided into Task Isolation Zones (shown in the diagram), Shared Resource Pools (shown in the diagram), and Kernel Space (shown in the diagram). Each created Task (shown in the diagram as TaskA, TaskB through TaskN) has its own independent memory region within the Task Isolation Zone. In terms of RAM access permissions, the entire system has Task permissions (restricted permissions), which control that Tasks can only access limited areas (shown in the diagram as TaskN Access Privilege, restricted permissions), including their respective independent memory regions and the shared resource pool. The monitoring task and the kernel possess the highest system privileges (high privileges, shown in the diagrams as Supervisor Task Access Privilege and Kernel Access Privilege), enabling them to access the entire memory domain.

[0025] Based on the above description, in an exemplary embodiment, taking task A as an example, the system memory can be partitioned as follows: Kernel code region: starting address 0x8000_0000, size 128KB.

[0026] Kernel data area: starting address 0x8002_0000, size 64KB.

[0027] Shared resource area: starting address 0x8003_0000, size 64KB.

[0028] Task A Private Area (i.e., Task A's independent memory area): Starting address 0x8004_0000, size 4KB.

[0029] After memory partitioning is complete, based on the processor's memory access control mechanism, access permissions are configured for each task, ensuring that each task can only access its own memory region and cannot access the memory regions of other tasks or the kernel. For data regions that need to be shared, a separate shared memory region is used, and its access permissions are controlled separately.

[0030] In practical implementation, the permission configuration of the aforementioned memory area is achieved by configuring the PMP register. In an exemplary embodiment, an xPMPRegion structure is added to the FreeRTOS Task Control Block (TCB) to store the pmpaddr and pmpcfg values ​​specific to the task, corresponding to the aforementioned system memory partitioning status. Detailed configuration parameters and explanations are shown in the table below: Furthermore, in practical implementations, due to constraints on region size and alignment imposed by the memory protection mechanisms of some processors (e.g., requiring region size to be fixed-granularity or aligned exponentially), this invention, when allocating task memory, performs upward alignment of the independent memory regions for each task based on its memory requirements, and protects and restricts redundant regions to prevent tasks from accessing other memory regions out of bounds. Simultaneously, a guard region is set at the boundary of the task stack area to trigger an exception promptly when a stack overflow occurs. For example, task A requires 1023B of space, but considering alignment requirements, this space needs to be configured as 1024B (upward alignment). The extra 1B here is the redundant region, which is set as a guard region. To prevent stack overflow, a certain size needs to be reserved at the actual stack boundary, for example, 1K.

[0031] Of course, it should be noted that the specific parameters configured above need to be determined according to the specific circumstances. The above is only an example used to describe the method provided by the embodiments of the present invention.

[0032] Step S102: When the task is running, the access control bits of the status register are configured to control data access to be executed with restricted privileges to access its independent memory area, and instruction execution to be executed with high privileges to access the entire memory domain. If a kernel function is called, the restricted privileges are removed by clearing the access control bits at the kernel entry point, and the restricted privileges are restored by resetting the access control bits at the kernel exit point.

[0033] During task execution, this embodiment of the invention uses a processor state control mechanism to restrict the task's data access permissions to the memory access control rules. Specifically, when a task is scheduled for execution, access control bits in the processor status register are set to ensure that data access is performed with restricted permissions, thereby being constrained by the memory protection mechanism. At the same time, the task's instruction execution remains at a high privilege level to ensure the normal operation of the system scheduling and exception handling mechanisms.

[0034] See Figure 4 This is a schematic diagram of a task execution permission model provided in an embodiment of the present invention, such as... Figure 4 Let's take a TaskN instance as an example to illustrate permission checks and usage. Specifically, TaskN and the RTOS Kernel run on the CPU. TaskN can perform two types of operations: data access (the lower curve corresponding to TaskN in the diagram) and instruction execution (the upper curve corresponding to TaskN in the diagram). The Kernel can also perform data access (the upper curve corresponding to Kernel in the diagram) and instruction execution (the lower curve corresponding to Kernel in the diagram). Instruction execution (e.g., instruction fetching operations, including TaskN and Kernel) and Kernel data access operations (e.g., data fetching operations) run with high privileges. Therefore, in the diagram, passing through the Invalid region of Privilege Control indicates that permission control is ineffective, and no permission check is performed (in the diagram, Privilege Check, R / W / X represent read, write, and execute permissions respectively), allowing access to the entire memory domain. However, TaskN's data access operations, passing through the Valid region of Privilege Control in the diagram, indicate that permission control is effective. A permission check is then performed, and access to the entire memory domain is restricted, limiting access to only the restricted area, namely TaskN's independent memory region. In summary, TaskN has low privileges and can only access designated memory regions when directly accessing memory; the Kernel has high privileges and can access the entire memory domain even under privilege checks and privilege control; if TaskN needs to access other memory regions, it can do so indirectly through the Kernel using system calls (i.e., calling kernel functions). It should be noted that... Figure 4The Privilege Control and Privilege Check shown are merely labels used to facilitate the description of the logical process of the task execution permission model; the permission control methods are all integrated into the task scheduler.

[0035] In this way, by separating instruction execution from data access permissions, restrictions on task data access behavior can be achieved without introducing additional privilege level switching overhead.

[0036] In an exemplary embodiment, when the scheduler is ready to jump to task A, it configures mstatus.MPRV = 1 and mstatus.MPP = 0x0 (in User mode). Although the CPU is executing in machine mode, all data read and write instructions are subject to the "sandbox" constraints defined by PMP for User mode.

[0037] In addition, to prevent tasks from bypassing the access control mechanism, this invention also restricts access to critical control registers. Specifically, this includes: prohibiting tasks from directly modifying critical bits in the memory protection configuration register or status register (for example, RISCV attempting to modify mstatus.MPRV=1, mstatus.mpp=0, etc.); triggering an exception and handing it over to the kernel for handling when a task attempts to execute related privileged instructions; or constraining the task code through compilation and runtime mechanisms to ensure the effectiveness of the access control mechanism.

[0038] When a task needs to call operating system kernel services (such as task management, synchronization mechanisms, or communication mechanisms), this invention temporarily elevates data access permissions at a unified entry point of the kernel function, enabling the kernel to access global memory regions. After the kernel function completes execution, the task's original restricted access permissions are restored. This permission switching process is implemented through a unified encapsulated entry and exit mechanism, such as through macros or function encapsulation, clearing access restrictions upon entering the kernel and restoring them upon exiting, thereby avoiding redundant implementation in various kernel functions and reducing the risk of errors.

[0039] For example, when a task calls a kernel function and enters the kernel, the software clears mstatus.MPRV at the kernel entry point and sets mstatus.MPRV at the function exit point. Through the above permission switching control, the permissions are immediately restored to the native machine mode. Without additional instructions, the kernel can access the entire memory for resource scheduling.

[0040] For nested kernel function calls, this invention records the current permission status using a counter or status flag, avoiding repeated permission switching or incorrect permission recovery during nested calls. During a kernel function call, a nesting identifier counts the number of nestings. This nesting count is incremented during nesting and decremented upon exiting the nest. When the nesting identifier reaches zero, the restricted permissions are restored at the kernel exit by resetting its access control bit. This ensures that when a kernel function calls another kernel function, permission switching only occurs at the outermost call, and the restricted state is restored only after all nested calls have returned.

[0041] Specifically, after entering the Kernel, nested calls to Kernel functions may occur. As described in the above embodiment, entering the Kernel requires privilege escalation (using RISCV as an example), i.e., configuring mstatus.MPRV=0 and mstatus.MPP=3. When the call ends, the configuration needs to be restored, i.e., configuring mstatus.MPRV=1 and mstatus.MPP=0. This embodiment sets a variable ui32NetFlag to monitor whether the Kernel has been completely exited. ui32NetFlag is incremented (accumulated) with each nesting, and decremented each time the nesting is exited. After completely exiting the Kernel, ui32NetFlag=0, at which point privilege demotion is performed.

[0042] Step S103: When interacting between tasks, call kernel functions to read and write messages from the message queue, or dynamically configure the corresponding task to read and write permissions for the reserved shared resource area in memory to read and write messages.

[0043] Under the task isolation mechanism, this invention does not allow tasks to communicate directly through uncontrolled global variables. Inter-task communication is implemented through controlled mechanisms provided by the kernel, including message queues and semaphores. For high-performance data exchange scenarios, this invention introduces a shared memory mechanism. The shared memory region is uniformly allocated by the system, and access is restricted through a memory access control mechanism. Task access to shared memory requires kernel authorization or is performed within predefined permission ranges, thereby ensuring the security of shared data. In the case of concurrent access to shared memory by multiple tasks, synchronization mechanisms (such as locks or semaphores) are used to avoid data conflicts or inconsistencies.

[0044] See Figure 5 This is a schematic diagram of an inter-task communication process provided in an embodiment of the present invention, such as... Figure 5This illustrates the process of inter-task communication in a system with isolated task memory spaces, using TaskA sending data and TaskB receiving data as an example. In an exemplary embodiment, a kernel function can be invoked to elevate data memory access privileges, thereby enabling information exchange via a message queue. TaskA elevates its data memory access privileges through a system call (Privilege Escalation in the diagram), sending an IPC message to the message queue. When the kernel schedules TaskB to run, it reads the message sent by TaskA from the queue and returns to TaskB's runtime, performing Privilege De-escalation. From the above description, it can be seen that Tasks have low data memory access privileges, while the kernel has high data memory access privileges.

[0045] In another exemplary embodiment, tasks can be dynamically configured to interact with each other regarding read and write permissions for the reserved shared resource area in memory. When TaskA sends data to TaskB, it first enters the Kernel via a system call (at which point the Kernel has high privileges). The Kernel configures TaskA to write to shared memory (dynamic config: W=1). After configuration, TaskA writes data to shared memory (Shared Memory, Space For TaskA in the diagram). Before the Kernel schedules TaskB to run, it dynamically configures (dynamic config: R=1) TaskB to read from shared memory. When TaskB runs, it can read data from shared memory. Because the Kernel elevates the privileges for writing and reading shared memory for TaskA and TaskB, both TaskA and TaskB have high privileges when writing to and reading from shared memory. It should be noted that in this embodiment, shared memory can be spatially considered as a subset of the shared resource pool, and a shared resource pool can be divided into multiple shared memories.

[0046] Specifically, in the first implementation scenario, inter-task interaction is achieved based on a kernel-intercepted controlled IPC mechanism, as follows: When task A (the first task) needs to send a message (such as a Queue message) to task B (the second task), the following steps are performed: System call trigger: Task A calls the first kernel function, such as xQueueGenericSend(), which sends data to the queue. At the entry point of the xQueueGenericSend() function, the software setting mstatus.MPRV is cleared. Data copy: xQueueGenericSend() copies the data of TaskA to the Queue Buffer; The xQueueGenericSend() function sets the mstatus.MPRV bit at its exit point; The scheduler schedules TaskB to run; TaskB calls the second kernel function xQueueReceive(), which reads and removes a data item from the queue. At the entry point of the xQueueReceive() function, the software setting mstatus.MPRV is cleared. xQueueReceive() reads the data written by TaskA from the Queue Buffer and returns it; The xQueueReceive() function outputs a setting in the software, which is mstatus.MPRV.

[0047] Through the above steps, data is securely transferred between two physically isolated sandboxes, and task A cannot directly access the memory of task B.

[0048] In the second implementation, based on PMP dynamic windows and zero-copy shared memory, especially for large data transfers (such as video streams and large arrays), dynamic permission mapping is used to achieve inter-task interaction, as follows: Static reservation: Reserve a 1K block of shared memory in RAM starting at address 0x8002_0000.

[0049] Access control transfer logic: When the scheduler schedules TaskA to run, it dynamically configures PMP to make TaskA writable to SharedMemory; when TaskA runs, it writes data to SharedMemory. When the scheduler schedules TaskB to run, it dynamically configures PMP to make TaskB readable to SharedMemory; when TaskB runs, it reads data from SharedMemory.

[0050] By using the "instant switching" of the PMP register, zero-copy high-efficiency communication is achieved under the premise of physical isolation.

[0051] Step S104: In response to a task exception, record the exception information and mark the task status as a fault state in a separate exception handling stack.

[0052] When an exception occurs during task execution, including illegal memory access, illegal instruction execution, stack overflow, or peripheral access error, the processor enters the exception handling process. In this embodiment of the invention, the processor first switches to an independent exception handling stack at the exception entry point. For potential extreme cases, such as a corrupted task stack or an exception occurring within an interrupt context, this invention uses a pre-allocated safety stack or a processor-independent exception stack to ensure that the exception handling process is independent of the task's runtime environment, thereby preventing further exception handling failures and guaranteeing the reliability of the exception handling process.

[0053] See Figure 6 This diagram illustrates an exception triggering and handling process provided by an embodiment of the present invention. As shown, when TaskN is running, if it crashes (failures), the system triggers an exception and enters the exception handling function (Trap Handler). The exception handling function only handles a limited amount of work to ensure the fastest possible exit from the exception handling process. In the exception handling process, exception information is recorded (by reading system exception handling-related registers, such as mcause, mepc, and mtval in RISCV), the status of TaskN is changed to FAILED (failure state), and the TaskN is removed from the ready list. This triggers the scheduling and execution of the Supervisor Task, which further processes the task that was just FAILED.

[0054] In the exception handling process, this invention follows the principle of minimization, performing only necessary operations, including exception information recording and task status marking. Specifically, the current task's state is marked from running to faulty, and relevant exception information, such as necessary context information including the program counter, exception address, and exception cause, is recorded for subsequent analysis and recovery. Complex operations, such as resource release, task deletion, or memory allocation, are not performed at this stage to avoid introducing new uncertainties or further damaging the system state in the exception context.

[0055] In an exemplary embodiment, when the system captures mcause = 0x7 (Store Access Fault), it is guided to the exception handler by mtvec. The illegal access address (such as 0x8002_1000) is read through mtval and compared with the current task profile to determine that it is an out-of-bounds access. Specifically, mcause = 0x7 indicates a memory access error, and mtval = 0x8002_1000 indicates that the address was accessed. The address configured for the task in the TCB is checked and does not contain 0x8002_1000, so it is determined to be an out-of-bounds access. The exception handler records the values ​​of mcause, mtval, and mepc. Among them, mcause records the reason for the error, mtval records the accessed address, and mepc records the address where the code is executed. This can be understood as follows: when the code executes to address A, an error occurs when accessing memory address B. At this time, mepc = A, mtval = B, and mcause = 0x7.

[0056] Step S105: Disable interrupts or use atomic operations to isolate tasks in a faulty state, while scheduling tasks in a normal state for execution.

[0057] After marking the faulty task, this invention performs isolation operations on the faulty task. Isolation methods include, but are not limited to: removing the faulty task from the scheduling queue so that it no longer participates in scheduling; tightening the task's memory access permissions, such as its access permissions to the corresponding independent memory region, so that it cannot access the valid memory region; marking the task as frozen and prohibiting it from continuing to execute.

[0058] During isolation, to prevent inconsistent scheduling states or interruptions, interrupts can be temporarily disabled or atomic operations can be used to ensure the integrity of the isolation operation. Interruptions can cause system scheduling, and once the system schedules, the task that needs to be isolated may run again. Therefore, in this embodiment of the invention, interrupts are temporarily disabled and then re-enabled after isolation is completed; or, if the system hardware supports atomic operations, corresponding registers can be configured to prevent interruption by other code execution during the isolation process. Through the above isolation mechanism, this embodiment of the invention can effectively block the impact of abnormal tasks on other parts of the system, thereby achieving controllable propagation of faults.

[0059] In one exemplary embodiment, the exception handling function removes the exception task from the ready task queue and triggers scheduling through the following code logic (represented in pseudocode): pxFaultTask = pxCurrentTCB; / / An exception has been detected in the current task. vTaskSuspend(pxFaultTask); / / Immediately remove from the ready queue portYIELD_WITHIN_API(); / / Trigger scheduling to skip faulty tasks In this way, the faulty task is locked instantly and no longer occupies CPU time.

[0060] Step S106: Based on the exception information, perform any one of the following operations on the task in the fault state: restart, downgrade, or delete and release resources.

[0061] This invention extends the task scheduler of the operating system to enable it to be aware of the task status. During scheduling, the task scheduler skips tasks that are in a faulty or frozen state and only selects normal tasks for scheduling and execution.

[0062] See Figure 7 This is a schematic diagram of a task state switching provided in an embodiment of the present invention, such as... Figure 7 As shown, the embodiments of the present invention include multiple task states, and the task scheduler selects according to the task state, thereby ensuring that the system can still operate normally when some tasks are abnormal.

[0063] Specifically, the states are: Ready (ready to run) means the task is ready to be scheduled by the scheduler; Running (running) means the task is currently running; Failed (faulted) means the task has encountered an error and has been removed from the ready queue, marked as such. Depending on the specific execution situation, a task in the faulted state can continue to the subsequent frozen state or deleted state; Frozen (frozen) means the fault situation is completely locked and will not be scheduled, but is added to the exception handling task list. Tasks in the frozen state can choose to enter the recovery state or deleted state depending on the scheduling situation; Recover (or blocked state) is a core intermediate state in the system's self-healing process and is not visible to the system scheduler. In this state, high-priority monitoring tasks perform surgical operations: forcibly stripping the mutex lock held by the task and transferring it to the first task in the blocked waiting queue, reclaiming its unreleased dynamic memory through the dynamic heap manager, and physically zeroing out the task's private stack space; Deleted (deleted) means the task has encountered an unrecoverable error and is marked as deleted, and will no longer run.

[0064] This invention provides a dedicated background processing task for further processing isolated faulty tasks. This processing is executed within a normal task context, thus avoiding the execution of complex logic in an abnormal context. The background processing task categorizes faulty tasks based on the exception type and historical information recorded in the exception information, including: reinitializing the task context and restarting the task; deleting the task and releasing its resources; and degrading the task, such as restricting its functionality or resource usage. For unrecoverable severe exceptions, the task can be directly deleted or a system-level processing strategy can be triggered. Furthermore, for cases of consecutive exceptions, this invention can set an exception counter for the task. When the same task triggers exceptions multiple times within a short period, stricter strategies can be adopted in subsequent processing stages, such as directly deleting the task or prohibiting its restart.

[0065] Furthermore, to ensure system consistency, this embodiment of the invention tracks the system resources occupied by a task during its execution, including mutex locks, queues, and peripheral resources. When a task encounters an anomaly, the resources it occupies are reclaimed during the background processing phase, including releasing locks, clearing queue states, and resetting peripherals. For cases where an anomaly occurs while a task is holding a lock, this invention forcibly releases the relevant lock resources to avoid system deadlock. For complex resources, such as DMA (Direct Memory Access) or peripheral operations, unified processing can be performed through the recovery interface provided by the driver layer, thereby ensuring the consistency of the overall system state.

[0066] In practical implementation, a task that crashes (a task in a faulty state) is an important task, and the number of times it fails within a time window T (a custom time) is less than N (a preset first threshold). In this case, the task stack can be reinitialized to allow the task to run again. Preferably, N can be defined as 5. It should be noted that the importance of tasks is configured according to specific system working scenarios through pre-setting priorities, etc., which will not be elaborated in this embodiment of the invention.

[0067] If a task crashes more than N times within the time window T, or directly accesses kernel region data, it is considered a dangerous task and will be deleted, banned from running, and its occupied resources will be reclaimed.

[0068] If a task fails to release heap memory due to frequent heap memory requests, this can be determined by checking if its memory request frequency exceeds a preset second threshold. Alternatively, if it causes excessive CPU utilization, such as exceeding a preset third threshold, the task's priority can be reduced.

[0069] In extreme cases, such as when all tasks are in a faulty state, embodiments of the present invention can also enter a safe mode, including executing an idle task, triggering a system degradation strategy, or performing a limited-range system recovery operation. An idle task refers to a task that is not running when no user tasks are running; this can be understood as the task not performing any action. Triggering a degradation strategy means changing the system state when no user tasks are running. Taking RISCV as an example: setting mstatus.mprv=1 and mstatus.mpp=0; resuming kernel operation achieves a limited-range system recovery. Since all user tasks have failed, only kernel operation is restored by enabling the system clock interrupt.

[0070] In an exemplary embodiment, the asynchronous processing and resource consistency recovery operation described in the above embodiments of the present invention is used to resolve the "residual risk" after a task crash, and can be specifically implemented in the following ways: Asynchronous cleanup: The Supervisor Task obtains a handle from the fault queue.

[0071] Resource reclamation: Iterate through the xHeldResourcesList held by the failed task and release the resources held by the task; if the task holds a mutex lock L and a task B is waiting, then execute: L->pxOwner = Task_B; vTaskResume(Task_B). By forcibly transferring lock ownership, system-level deadlocks are prevented.

[0072] Hot restart: Resets the stack pointer (SP) and program counter (PC) of the failed task, clears its independent memory area, and puts it back into operation.

[0073] Task failure detection: If a task fails for the same reason a number of times consecutively is greater than or equal to N, the task will no longer be put into operation (i.e., it will no longer be hot-restarted).

[0074] As can be seen from the description of the above embodiments, the task control method provided by the embodiments of the present invention allocates an independent memory region for each task in memory; during task execution, by configuring the access control bits of the status register, data access is controlled to be executed with restricted privileges to access its independent memory region, and instruction execution is executed with high privileges to access the entire memory domain; if a kernel function is called, the restricted privileges are removed by clearing the access control bits at the kernel entry point, and the restricted privileges are restored by resetting the access control bits at the kernel exit point; when tasks interact, kernel functions are called to read and write messages from the message queue, or the read and write permissions of the corresponding task to the reserved shared resource area in memory are dynamically configured to read and write messages; in response to task exceptions, exception information is recorded in an independent exception handling stack and the task status is marked as a fault state; interrupts are masked or atomic operations are used to isolate the fault state task, while scheduling the execution of the normal state task; based on the exception information, any one of the following operations is performed on the fault state task: restart, downgrade, or delete and release resources. This invention isolates and recovers task-level faults in real-time operating systems based on processor memory access control mechanisms. By constraining memory access behavior during task execution and combining exception capture, scheduling coordination, and resource recovery mechanisms, it achieves task-level fault isolation and online recovery, thereby realizing high-granularity and high-precision task control, effectively preventing single task anomalies from causing the entire system to crash, and thus improving system reliability.

[0075] In summary, the specific effects of this invention are as follows: It achieves task-level hardware-level physical isolation by utilizing the processor's built-in memory protection unit and privileged-level simulation mechanism to construct an independent, restricted virtual private address space (sandbox) for each real-time task. This ensures that tasks can only access their legal code segments, stack areas, and authorized peripheral resources during execution, physically eliminating the risk of kernel or other task data being tampered with due to wild pointers, out-of-bounds access, or stack overflows from a single task. It provides an efficient and low-cost dynamic permission switching mechanism by dynamically reconstructing memory protection rules during task context switching and combining this with privileged-level mapping technology (such as simulating non-privileged mode access). This ensures that tasks, even when running in machine mode or high-privilege mode, are still subject to strict memory access constraints, while minimizing real-time performance loss and computational overhead caused by software intervention. It achieves precise capture and seamless isolation of faulty tasks by establishing a mechanism that links anomaly response with the scheduler. When hardware captures a memory access violation, the system can accurately identify the faulty task and immediately remove it from the current ready queue, thus limiting the impact of the fault to the affected task and ensuring the continuous and uninterrupted operation of the system kernel and other healthy tasks, significantly improving the overall reliability of the system. To address resource remnants and deadlocks following task crashes, a kernel-level resource monitoring list (including mutexes, semaphores, and dynamic memory) is established. After a task is forcibly terminated due to a fault, the kernel automatically performs a resource reclamation process. By forcibly releasing synchronization primitives held by the failed task or safely transferring ownership to waiting objects, the system-level deadlock risk caused by task crashes is completely eliminated. A business-level asynchronous self-healing and restart guarantee mechanism is established: This aims to provide a flexible task recovery framework. Through background monitoring tasks or system hook functions, isolated failed tasks are cleaned up, their states are reset, and on-demand restarts are performed. Automatic repair of business functions is achieved without a global reset, minimizing downtime caused by occasional task failures. Balancing high security and efficient inter-task communication, under a framework of forced isolation, controlled, high-performance data interaction between tasks is achieved by dynamically adjusting access permissions for specific memory windows. This balances the technical contradiction between "strong isolation" and "high collaboration," improving the engineering practicality of multi-task collaborative systems.

[0076] Through the description of the above method embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0077] This invention provides a non-volatile computer storage medium storing computer-executable instructions that can execute the task control method in any of the above method embodiments.

[0078] Corresponding to the task control method embodiment provided by the present invention, the present invention also provides a task control device.

[0079] See Figure 8 Figure 1 is a schematic diagram of a task control device provided in an embodiment of the present invention. As shown in the figure, the device includes: Allocation module 11 is used to allocate an independent memory region for each task in memory; The permission module 12 is used to control data access to its independent memory region and instruction execution to the full memory domain by configuring the access control bits in the status register during task runtime. If a kernel function is called, the restricted permissions are removed by clearing the access control bits at the kernel entry point and the restricted permissions are restored by resetting the access control bits at the kernel exit point. Interaction module 13 is used to call kernel functions to read and write messages from the message queue when interacting between tasks, or to dynamically configure the corresponding task's read and write permissions for the reserved shared resource area in memory to read and write messages. The marking module 14 is used to record exception information and mark the task status as a fault state in a separate exception handling stack in response to task exceptions. Isolation module 15 is used to shield interrupts or use atomic operations to isolate tasks in a fault state, while scheduling and executing tasks in a normal state. The exception handling module 16 is used to perform any one of the following operations on a task in a fault state based on exception information: restart, downgrade, or delete and release resources.

[0080] Figure 9This is a schematic diagram of the hardware structure of the electronic device for implementing the task control method provided in an embodiment of the present invention, as shown below. Figure 9 As shown, the device includes: One or more processors 910 and memory 920, Figure 9 Take the 910 processor as an example.

[0081] The device for performing the task control method may further include an input device 930 and an output device 940.

[0082] The processor 910, memory 920, input device 930, and output device 940 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0083] The memory 920, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the task control method in this embodiment of the invention (e.g., attached...). Figure 8 The diagram shows the allocation module 11, permission module 12, interaction module 13, marking module 14, isolation module 15, and exception handling module 16. The processor 910 executes various server functions and data processing by running non-volatile software programs, instructions, and modules stored in the memory 920, thereby implementing the task control method described in the above embodiment.

[0084] The memory 920 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the task-controlled processing device. Furthermore, the memory 920 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 920 may optionally include memory remotely located relative to the processor 910, and these remote memories may be connected to the task-controlled processing device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0085] Input device 930 can receive input digital or character information, and generate key signal inputs related to user settings and function control of the task control processing device. Output device 940 may include display devices such as a display screen.

[0086] The one or more modules are stored in the memory 920, and when executed by the one or more processors 910, they execute the task control method in any of the above method embodiments.

[0087] The above-described product can execute the method provided in the embodiments of the present invention, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the method provided in the embodiments of the present invention.

[0088] The electronic devices of this invention exist in various forms, including but not limited to: (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0089] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0090] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes: audio and video players (such as iPods), handheld game consoles, e-books, as well as smart toys and portable car navigation devices.

[0091] (4) Server: A device that provides computing services. The components of a server include a processor, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0092] (5) Other electronic devices with data interaction functions.

[0093] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0094] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatus or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The apparatus and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0096] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A task control method, characterized in that, include: Each task has its own independent memory region allocated in memory. During task execution, the access control bits in the status register are configured to control data access to be executed with restricted privileges to access its independent memory region, and instruction execution to be executed with high privileges to access the entire memory domain. If a kernel function is called, the restricted privileges are removed by clearing the access control bits at the kernel entry point, and the restricted privileges are restored by resetting the access control bits at the kernel exit point. When interacting with other tasks, kernel functions are called to read and write messages from the message queue, or the corresponding task is dynamically configured to read and write permissions to the reserved shared resource area in memory to read and write messages. In response to task exceptions, exception information is recorded in a separate exception handling stack, and the task status is marked as a fault state. Disabling interrupts or using atomic operations can isolate tasks in a faulty state while scheduling tasks in a normal state for execution. Based on the anomaly information, perform one of the following operations on the faulty task: restart, downgrade, or delete and release resources.

2. The task control method according to claim 1, characterized in that, The allocation of an independent memory region for each task in the memory includes allocating its independent memory region upwards according to the memory requirements of each task. If an independent memory region exceeds the memory requirement, the excess independent memory region will be configured as a protected region to prevent out-of-bounds access.

3. The task control method according to claim 1, characterized in that, The step of restoring restricted privileges at the kernel exit by resetting its access control bits includes: during the call to a kernel function, counting the number of nestings using a nesting identifier, which is accumulated when nesting and decremented when exiting nesting; when the nesting identifier is zero, restoring restricted privileges at the kernel exit by resetting its access control bits.

4. The task control method according to claim 1, characterized in that, The task of isolating fault states includes performing any of the following operations: Remove tasks in a faulty state from the scheduling queue so that they are not subject to scheduling; Cancel access permissions of a failed task to its independent memory region; Mark the task in a faulty state as frozen and prevent it from executing.

5. The task control method according to claim 1, characterized in that, The operation of restarting, downgrading, or deleting and releasing resources for a task in a faulty state based on anomaly information includes: If a task is considered important and the number of failures within a preset time window is less than a first threshold, a restart operation will be performed to allow the task to run again. When the number of times a task fails within a preset time window exceeds the first threshold, or when a task directly accesses the corresponding memory region of the kernel, a deletion and resource release operation is performed to prevent it from running and reclaim the resources it occupies. When a task requests memory more frequently than the second threshold and fails to release the requested memory, or when processor utilization exceeds the third threshold, a demotion operation is performed to lower its priority.

6. The task control method according to claim 1, characterized in that, It also includes the ability to perform any of the following operations when all tasks are in a faulty state: idle task, system degradation, and recovery of the running core.

7. The task control method according to claim 1, characterized in that, When the first task sends data to the second task, during the inter-task interaction, kernel functions are called to read and write data from the message queue, including: The first task is to remove restricted permissions by calling the first kernel function, send the data to the message queue, and restore restricted permissions after the data is sent. The second task is to remove restricted permissions by calling the second kernel function, read data from the message queue, and restore restricted permissions after reading is complete. The dynamic configuration corresponds to the task's read and write permissions for the reserved shared resource area in memory, as well as read and write messages, including: Configure the first task to have write permissions to the reserved shared resource area, and write the data to the reserved shared resource area; Configure the second task to have read permissions for the reserved shared resource area, and read data from the reserved shared resource area.

8. A task control device, characterized in that, The device includes: The allocation module is used to allocate an independent memory region for each task in memory; The permissions module is used during task runtime to control data access to its independent memory region by configuring the access control bits in the status register, and instruction execution to the entire memory domain by executing with high privileges. If a kernel function is called, the restricted permissions are removed at the kernel entry point by clearing the access control bits, and the restricted permissions are restored at the kernel exit by resetting the access control bits. The interaction module is used to call kernel functions to read and write messages from the message queue when interacting between tasks, or to dynamically configure the corresponding task's read and write permissions for the reserved shared resource area in memory to read and write messages. The marking module is used to respond to task exceptions by recording exception information and marking the task status as a fault state in a separate exception handling stack. The isolation module is used to shield interrupts or use atomic operations to isolate tasks in a faulty state, while scheduling and executing tasks in a normal state. The exception handling module is used to perform any one of the following operations on a task in a faulty state based on exception information: restart, downgrade, or delete and release resources.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the task control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the steps of the task control method as described in any one of claims 1 to 7.

Images