Embedded task status detection methods, devices, systems, and storage media

Abstract

This application provides an embedded task state detection method, device, system, and storage medium. In this application, when a task transitions from a non-ready state to a ready state, the ready time of the task in the ready state is recorded. The length of the ready time represents the time during which the task cannot be scheduled. Monitoring whether a task has timed out by using the time during which it cannot be scheduled provides higher accuracy and avoids false alarms. For example, if task C is starved due to an infinite loop between tasks A and B, it will be detected when the ready time of task C exceeds a set time threshold, preventing false alarms. As another example, if task A in the system has a heavy load exceeding the CPU utilization threshold (e.g., 90%), but other tasks with lighter loads are also scheduled, the ready times of the other tasks with lighter loads will not exceed the set time threshold, thus preventing false alarms about task A's heavy load causing a scheduling timeout.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to a method, device, system, and storage medium for detecting the state of an embedded task. Background Technology

[0002] In embedded operating systems, if a single task or multiple tasks occupy the Central Processing Unit (CPU) for an extended period, other tasks will be starved due to prolonged lack of scheduling. When task starvation occurs, it poses serious risks to system operation; therefore, it is essential to detect and address task starvation promptly. Current embedded operating systems typically detect task starvation by checking for tasks with CPU utilization exceeding a set threshold, and by detecting task starvation, they can then determine whether task starvation has occurred.

[0003] This method of detecting task starvation is prone to misjudgment and cannot accurately detect task starvation. For example, when two tasks of the same priority enter an infinite loop, based on the round-robin scheduling algorithm, each task's CPU utilization is 50%. From the perspective of a single task, its CPU utilization has not reached the set threshold (e.g., 90%), thus it will be misjudged as not having a task starvation in the system. Furthermore, this method is also prone to misjudgment when a task is heavily loaded. For instance, if a task's CPU utilization exceeds the set threshold (e.g., 90%) but it is not in an infinite loop, and other lightly loaded tasks are not starved, this method will misjudge that task starvation has occurred in the system. Summary of the Invention

[0004] This application provides a method, device, system, and storage medium for embedded task status detection, which can accurately monitor task starvation problems in embedded operating systems and thus solve system operation risks caused by task starvation.

[0005] This application provides an embedded task state detection method, including: during the operation of an embedded operating system, monitoring a task that has entered a ready state from a non-ready state, recording the ready time of the task in the ready state; and when a first task is identified based on the ready time, performing timeout scheduling processing on the first task.

[0006] This application embodiment also provides an embedded task state detection method, including: during the operation of the embedded operating system, monitoring a specific lock and recording the lock holding time of the specific lock; when a target lock is identified based on the lock holding time, obtaining the task requesting the target lock, and performing timeout scheduling processing on the task.

[0007] This application embodiment also provides an embedded operating system, including: a task monitoring module, used to monitor tasks that enter the ready state from the non-ready state during the operation of the embedded operating system; a ready time recording module, used to record the ready time of the task in the ready state; and a processing module, used to perform timeout scheduling processing on the first task when the first task is identified according to the ready time.

[0008] This application embodiment also provides an embedded operating system, including: a lock monitoring module for monitoring a specific lock during the operation of the embedded operating system; a lock holding time recording module for recording the lock holding time of the specific lock; and a processing module for obtaining a task requesting the target lock when a target lock is identified based on the lock holding time, and performing timeout scheduling processing on the task.

[0009] This application embodiment also provides an embedded device, including: a memory and a processor; the memory stores program code corresponding to an embedded operating system; the processor is coupled to the memory and is used to execute the program code corresponding to the embedded operating system, for: monitoring a task that enters a ready state from a non-ready state during the operation of the embedded operating system, recording the ready time of the task in the ready state; and, in the case of a first task identified according to the ready time, performing timeout scheduling processing on the first task.

[0010] This application embodiment also provides an embedded device, including: a memory and a processor; the memory stores program code corresponding to an embedded operating system; the processor is coupled to the memory and is used to execute the program code corresponding to the embedded operating system, for: monitoring a specific lock during the operation of the embedded operating system and recording the lock holding time of the specific lock; and, if a target lock is identified based on the lock holding time, obtaining a task requesting the target lock and performing timeout scheduling processing on the task.

[0011] This application also provides a computer-readable storage medium storing program code corresponding to an embedded operating system. When the program code corresponding to the embedded operating system is executed by a processor, the processor causes the processor to implement the steps in the embedded task state detection method provided in this application.

[0012] This application embodiment also provides a task state detection method, including: monitoring a task that enters a ready state from a non-ready state during the operation of a non-embedded operating system; recording the ready time of the task in the ready state; and performing timeout scheduling processing on the first task when a first task is identified based on the ready time.

[0013] This application embodiment also provides a non-embedded operating system, including: a task monitoring module, used to monitor tasks that enter the ready state from the non-ready state during the operation of the non-embedded operating system; a ready time recording module, used to record the ready time of the task in the ready state; and a processing module, used to perform timeout scheduling processing on the first task when the first task is identified according to the ready time.

[0014] This application embodiment also provides a task status detection method, including: during the operation of a non-embedded operating system, monitoring a specific lock and recording the lock holding time of the specific lock; when a target lock is identified based on the lock holding time, obtaining the task requesting the target lock, and performing timeout scheduling processing on the task.

[0015] This application embodiment also provides a non-embedded operating system, including: a lock monitoring module, used to monitor a specific lock during the operation of the non-embedded operating system; a lock occupancy time recording module, used to record the lock occupancy time of the specific lock; and a processing module, used to obtain a task requesting the target lock when the target lock is identified based on the lock occupancy time, and to perform timeout scheduling processing on the task.

[0016] In this embodiment, when a task transitions from a non-ready state to a ready state, the ready time of that task in the ready state is recorded. The length of the ready time indicates the time during which the task cannot be scheduled. Monitoring whether a task is starving by measuring the time it remains unscheduled provides higher accuracy and avoids false positives. For example, if task C is starved due to an infinite loop between tasks A and B, it will be detected once task C's ready time exceeds a set time threshold, preventing false positives. Similarly, if task A in the system has a heavy load exceeding the CPU utilization threshold (e.g., 90%), but other tasks with lighter loads are also scheduled, the ready times of the lighter-loaded tasks will not exceed the set time threshold, thus preventing false positives due to task A's heavy load. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1a A schematic diagram of the composition of an embedded device provided for an exemplary embodiment of this application;

[0019] Figure 1b A schematic diagram of the structure of an embedded operating system provided as an exemplary embodiment of this application;

[0020] Figure 1c A schematic diagram of another embedded operating system provided as an exemplary embodiment of this application;

[0021] Figure 1d A schematic diagram of the structure of another embedded operating system provided as an exemplary embodiment of this application;

[0022] Figure 2 A schematic diagram of a task state transition relationship provided for an exemplary embodiment of this application;

[0023] Figure 3a A flowchart illustrating an embedded task state detection method provided for an exemplary embodiment of this application;

[0024] Figure 3b A flowchart illustrating another embedded task state detection method provided for an exemplary embodiment of this application;

[0025] Figure 3c A flowchart illustrating yet another embedded task state detection method provided for an exemplary embodiment of this application;

[0026] Figure 4 A flowchart illustrating another embedded task state detection method provided as an exemplary embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] To address the technical problem of misjudgment in existing embedded operating systems' methods for detecting task starvation, this application embodiment records the ready time of a task when it transitions from a non-ready state to a ready state. The length of the ready time indicates the time during which the task cannot be scheduled. Monitoring whether a task is starving by measuring the time during which a task cannot be scheduled is more accurate and avoids misjudgment.

[0029] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0030] Figure 1a This is a schematic diagram illustrating the composition of an embedded device provided as an exemplary embodiment of this application. The embedded device is a dedicated computer application system tailored to application requirements or scenarios. Figure 1aAs shown, the embedded device 100 includes a hardware subsystem 10 and a software subsystem 20. The hardware subsystem 10 is the foundation for the operation of the software subsystem 20 in the embedded device 100. It provides the physical platform and communication interface for the operation of the software subsystem 20. The software subsystem 20 is the control core of the embedded device 100, which controls the operation of the entire device and provides information for human-computer interaction.

[0031] like Figure 1a As shown, the hardware subsystem 10 includes an embedded processor 101 and a memory 102 coupled to the processor 101. Optionally, the hardware subsystem 10 may also include other peripheral hardware modules, such as an input interface 103, an output interface 104, a power management module 105, and / or a touchscreen 106, a keyboard 107, and / or a mouse 108 for human-computer interaction. Figure 1a In the diagram, optional peripheral hardware modules are indicated by dashed boxes.

[0032] The processor 101 is the hardware core of the embedded device 100. It can be implemented using a system-on-a-chip (SOPC), a system-on-a-chip (SOC), a central processing unit (CPU), a digital signal processor (DSP), or a microcontroller unit (MCU), but is not limited to these.

[0033] Memory 102 provides storage space for embedded device 100, which can be used to store various program codes corresponding to software subsystem 20, and can be configured to store various other data to support operations on embedded device 100. Examples of this data include instructions, messages, images, videos, etc., for any application or method operating on embedded device 100.

[0034] The memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0035] Input interface 103 and output interface 104 are communication interfaces for embedded device 100 to communicate with the outside world. They can use, but are not limited to, the following interface methods: USB bus, serial port, 1394 bus, Ethernet, IIS, CAN, DMA or GPIO.

[0036] The power management module 105 is responsible for providing power to the various hardware modules of the embedded device 100. The power management module 105 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power components are located.

[0037] The touchscreen 106, keyboard 107, and / or mouse 108 serve as input devices for the embedded device 100, responding to user input commands and inputting relevant information into the embedded device 100. Additionally, the touchscreen 106 can also serve as an output device for the embedded device 100, outputting relevant information to the user. Of course, besides the touchscreen 106, the embedded device 100 may also include an audio module 109 for receiving user voice commands or outputting relevant information to the user via voice.

[0038] like Figure 1a As shown, the software subsystem 20 includes an embedded operating system 201. The embedded operating system 201 is system software responsible for controlling and managing various hardware and software resources of the embedded device 100, such as hardware drivers, memory management, and task management. The program code corresponding to the embedded operating system 201 is stored in the memory 102. During the startup or normal operation of the embedded device 100, the processor 101 can load the program code corresponding to the embedded operating system 201 stored in the memory 102 to implement various control or drive functions of the embedded operating system 201, so as to successfully start the embedded device 100 or ensure its normal operation. The embedded operating system 201 can be a real-time operating system (RTOS) or a non-real-time operating system. An RTOS is an operating system that can accept and process external events or data at a sufficiently fast speed, and whose processing results can control the production process or respond quickly to the processing system within a specified time, scheduling all available resources to complete real-time tasks and controlling all real-time tasks to run in a coordinated manner. For example, the embedded operating system 201 can be a real-time operating system μC / OS-II or VxWorks, or a non-real-time operating system such as embedded Linux or Windows Embedded.

[0039] Furthermore, such as Figure 1aAs shown, the software subsystem 20 may also include embedded application software 202. Embedded application software 202 is application software, oriented towards specific application needs or scenarios. Depending on the application needs or scenarios, the functions implemented by embedded application software 202 will vary. For example, embedded application software 202 can be mobile phone software, router software, switch software, or flight control software, etc. It should be noted that application software 202 is optional, not mandatory, and its specific implementation depends on the application requirements of the embedded device.

[0040] In this embodiment, the focus is on the embedded operating system 201, particularly its task management functionality. The embedded operating system 201 in this embodiment differs from those in traditional embedded devices. In addition to traditional task management functions, the embedded operating system 201 in the embedded device 100 of this embodiment can also detect task status, identify task starvation, and handle starved tasks accordingly. Task starvation refers to a task state where it cannot be scheduled for an extended period due to various reasons, such as the inability to obtain processor resources, I / O resources, or other resources. Tasks have an upper limit for waiting to be scheduled. If the embedded operating system 201 cannot guarantee that a task will be scheduled within this upper limit, the task will remain unscheduled for an extended period. When the waiting time significantly negatively impacts task progress and response, task starvation is considered to have occurred. The processor 101 executes the program code corresponding to the embedded operating system 201 stored in the memory 102, implementing traditional task management functions as well as various functions related to task status detection. The following section provides a detailed explanation of the working principle of the embedded operating system 201 in this embodiment, focusing on task management:

[0041] Task management is a primary function of the embedded operating system 201. In this embodiment, task management includes, but is not limited to, task creation, task deletion, task scheduling, changing task priority, and task status detection. It should be noted that "task" is a conceptual term. In this embodiment, a task can be understood as a specific function that the embedded device 100 can perform. The functions that the embedded device 100 can perform are defined during the design of the embedded device 100. The functions that the embedded device 100 can perform will vary depending on different application requirements or scenarios. Within the embedded device 100, tasks can be completed by threads or processes.

[0042] In this embodiment, tasks in the embedded device 100 have the following states: Ready, Running, Blocked, and Suspended. Of course, tasks in the embedded device 100 may have other states besides these, which is not limited. The Ready state refers to a state where the task is capable of execution but has not yet started because a task of the same or higher priority is occupying processor resources. The Ready state is different from the Blocked and Suspended states. The Running state refers to a state where the task is actually being executed; tasks in the Running state occupy processor resources. It should be noted that the number of tasks in the Running state at the same time is related to the number of cores in the processor 101; if the processor 101 has only one core, only one task can be in the Running state at the same time; if the processor 101 has multiple cores, multiple tasks can be in the Running state simultaneously. The Blocked state refers to a state where the task is waiting for a temporary or external event; in other words, if a task needs to wait for a temporary or external event, the task will enter the Blocked state. A task in the blocked state corresponds to a blocking delay. During this delay, the task waits for a temporary or external event to occur successfully. After the delay ends, the task is unblocked, even if the event it was waiting for did not occur. Furthermore, a task in the blocked state does not occupy any processor time and will not be selected to enter the running state. Suspended state: This is also a task state. A task in the suspended state will never return to the ready state or be selected to enter the running state unless it is resumed. Unlike tasks in the blocked state, tasks in the suspended state do not have a corresponding delay time.

[0043] The task will transition between different states, and the transition relationships between task states are as follows: Figure 2 As shown. Figure 2 The transition relationships of the task states shown are as follows: When a new task is created, the new task will enter the ready state from the uncreated state; when a task in the ready state is scheduled, it will enter the running state; when a task in the running state is preempted by other tasks (such as higher priority tasks), the task will return from the running state to the ready state; when a task in the running state needs to wait for a temporary or external event to occur, it will enter the blocked state; when the waited temporary or external event successfully occurs within the corresponding blocking delay, the task in the blocked state will re-enter the running state; when the waited temporary or external event does not occur within the corresponding blocking delay, the task in the blocked state will re-enter the ready state.

[0044] Additionally, a running task can suspend itself via API calls, transitioning from the running state to the suspended state; conversely, a ready task can be suspended by a currently running task, transitioning from the ready state to the suspended state. A suspended task can only wait for the currently running task to interrupt or wake it up. Once woken up, a suspended task will enter the ready state. It's important to note that regardless of whether a task enters the ready state from the suspended state, from the uncreated state, or from the blocked state, if its priority is higher than that of the currently running task, the system will immediately allocate processor resources to the ready task, and it will immediately enter the running state. The priority allocation between tasks is also handled by the embedded operating system 201, which will not be detailed here.

[0045] In this embodiment, in addition to being responsible for the various task management operations described above, the embedded operating system 201 can also monitor whether a task enters the ready state from the non-ready state during the operation of the embedded device 100. If a task enters the ready state from the non-ready state, the system starts to count the ready time of the task in the ready state and records the ready time of the task in the ready state.

[0046] For any task, its readiness time refers to the duration the task remains in the ready state. This readiness time directly reflects whether the corresponding task is in a starved state. A starved state refers to a task that, for some reason, has not been scheduled for an extended period, exceeding the maximum time the task can wait to be scheduled. Therefore, a starved state can also be called a timed-out scheduling state. Based on this, the embedded operating system 201 can also identify whether a first task in a timed-out scheduling state exists based on the task's readiness time. If a first task is identified, timed-out scheduling is performed on that task to promptly resolve various anomalies caused by timed-out scheduling. In this embodiment, a task in a timed-out scheduling state is referred to as a first task. A first task can be any task in the ready state, and its number can be one or more. It should be noted that in the embodiments of this application, "starved" and "timed-out scheduling" have the same meaning, and either can be used in the description, and they can be substituted for each other.

[0047] Optionally, in some embodiments of this application, a ready time threshold can be set. If the ready time of a task is greater than the set ready time threshold, it indicates that the task has not been scheduled for a long time and is in a starved state (or timed-out scheduling state). Conversely, if the ready time of a task is less than or equal to the set ready time threshold, it indicates that the task has not been waiting for scheduling for a long time and is not in a starved state, and can continue to wait for scheduling. The ready time threshold can be greater than or equal to the upper limit of the time a task waits to be scheduled.

[0048] Based on the above, the embedded operating system 201 can also monitor whether any task in the ready state has a ready time greater than a set ready time threshold. If a task with a ready time greater than the set ready time threshold is detected, it can be determined that the task has been timed out (or starved), and timeout scheduling processing is performed on the task to promptly resolve various abnormal situations caused by task timeout scheduling. For ease of description and distinction, in these embodiments, the task with a ready time greater than the set ready time threshold is the first task. In this embodiment, the value of the ready time threshold is not limited; for example, it can be 10s, 30s, 1 minute, 2 minutes, 5 minutes, etc.

[0049] In this embodiment, the non-ready state refers to any task state other than the ready state, such as the uncreated state, running state, blocked state, or suspended state. Therefore, in this embodiment, the process of monitoring a task transitioning from the non-ready state to the ready state can include at least one of the following:

[0050] Scenario A1: When a new task is detected, it is determined that the new task will enter the ready state from the uncreated state.

[0051] Case A2: When it is detected that a task in the blocked state can enter the ready state after the blocking delay ends;

[0052] Case A3: When it is detected that a running task is preempted by another task, it is determined that the running task can transition from the running state to the ready state.

[0053] Case A4: When it is detected that a task in a suspended state is awakened by a running task, it is determined that the task in the suspended state can enter the ready state from the suspended state.

[0054] In other words, the embedded operating system 201 can monitor whether any of the above situations A1-A4 occur during operation. When any of the situations is detected, it starts to count and record the ready time of the task that enters the ready state under that situation, providing a basis for further discovering task timeout scheduling (or starvation) problems.

[0055] Further, optionally, combined Figure 2 As shown in the transition relationships between task states, for any task, in addition to transitioning from the suspended, running, blocked, or uncreated state to the ready state, the task can also transition from the ready state to the suspended or running state. Based on this, the embedded operating system 201 also monitors tasks transitioning from the ready state to the non-ready state, and when it detects a task transitioning from the ready state to the non-ready state, it resets the task's ready time to zero to ensure that the ready time accurately reflects the duration the task has been waiting for scheduling. The process of monitoring tasks transitioning from the ready state to the non-ready state includes at least one of the following:

[0056] Case B1: When a task in the ready state is monitored to be scheduled, determine that the task in the ready state will enter the running state (i.e., the non-ready state).

[0057] Case B2: When it is detected that a task in the ready state is suspended by a running task, determine that the task in the ready state will enter the suspended state (i.e., non-ready state).

[0058] In other words, the embedded operating system 201 can monitor whether any of the above situations B1-B2 occur during operation. When any of these situations are detected, the ready time of the task that enters the non-ready state under that situation is reset to zero.

[0059] As can be seen from the above, in this embodiment, by improving the embedded operating system in the embedded device, an embedded operating system 201 with task status detection function is provided, which solves the problem of task timeout scheduling (i.e. starvation) detection at the system level; moreover, by using the length of time a task is in the ready state to indicate the time during which the task cannot be scheduled, the accuracy of monitoring whether the task has timed out (i.e. starved) is higher and there will be no false judgment.

[0060] For example, suppose that during the operation of embedded device 100, there are tasks A, B, and C simultaneously, and tasks A and B are in an infinite loop, meaning they continuously occupy processor resources. In this case, task C will not be scheduled due to the infinite loop of tasks A and B, thus becoming starved. In this embodiment, the embedded operating system 201 can start recording the ready time of task C when it detects that task C has entered the ready state. When the ready time of task C exceeds a set ready time threshold, task C will be determined to be a starved task (i.e., task C has experienced starvation), and timeout scheduling will be performed on task C. Moreover, regardless of the processor resource utilization threshold set, it can successfully and timely detect that task C is starved (i.e., timeout scheduling), and will not mistakenly judge task C as not being starved because the utilization rates of tasks A and B have not reached the set resource utilization threshold.

[0061] For example, suppose that during the operation of embedded device 100, there are tasks A, B, and C simultaneously. Task A has a heavy load, causing its utilization of processor resources to exceed a set utilization threshold (e.g., 90%). However, tasks B and C, with lighter loads, are also scheduled. That is, when the embedded operating system 201 detects that tasks B and C have entered the ready state, it starts recording the ready time of tasks B and C in the ready state. Since the ready time of both tasks B and C does not exceed the set ready time threshold, tasks B and C are not starved. Therefore, tasks B and C will not be mistakenly judged as starved tasks because task A's utilization of processor resources exceeds the set utilization threshold.

[0062] In this embodiment, when a first task is detected to be starved, timeout scheduling can be performed on the first task. This embodiment does not limit the method of timeout scheduling for the first task. For example, information about the first task can be output to issue a timeout scheduling alarm (i.e., a starvation alarm). The information about the first task includes its identification information, such as the name of the first task, or the thread number or process number corresponding to the first task. Further optionally, the information about the first task may also include other information such as the ready time when the first task is in the ready state.

[0063] In addition to the timeout scheduling handling method described above, in the optional embodiments of this application, it is also possible to simultaneously monitor which task caused the first task to be starved. In this embodiment, the task that caused the first task to be starved is referred to as the third task, thereby triggering a starvation alarm for the first task. In the alarm handling for the first task, not only can the starved first task be output, but also the third task that caused the first task to be starved can be output simultaneously. The third task is a task that occupies the resources required by the first task for a long time without releasing them. To facilitate monitoring the third task that caused the starvation of a task while monitoring the starved task, in this embodiment of the application, a period can be set. The embedded operating system 201 can record the running time of each task scheduled for execution within each period, with the period as the granularity. It should be noted that, for the case where the processor 101 contains a single core, there may be multiple tasks scheduled for execution within each period. These multiple tasks are scheduled for execution in different time slots, meaning that only one task is running at any given time. Furthermore, the same task may be scheduled for execution once or multiple times within the same period. When a task is scheduled for execution multiple times within the same cycle, its runtime within that cycle is the sum of the runtimes of each scheduled execution. When a task is scheduled for execution only once within the same cycle, its runtime within that cycle is simply the runtime of that single scheduled execution. The runtime of each scheduled execution refers to the time the task occupies processor resources. Furthermore, at the end of each cycle, the recorded runtimes of all scheduled tasks within that cycle can be reset to zero, allowing for the re-recording of runtimes in the next cycle.

[0064] Based on the above, when the first task is identified, the embedded operating system 201 can obtain the task whose running time is greater than a set running time threshold within the current cycle as the third task causing the first task to starve. In this embodiment, the value of the running time threshold is not limited; for example, it can be 30 seconds, 1 minute, 5 minutes, etc. Alternatively, when the first task is identified, the embedded operating system 201 can obtain the task with the longest running time within the current cycle as the third task causing the first task to starve. Optionally, in one alternative embodiment, when the first task is identified, the embedded operating system 201 can directly obtain the task with the longest running time within the current cycle as the third task causing the first task to starve. In another alternative embodiment, when the first task is identified, the embedded operating system 201 can determine whether there is a task with a running time greater than a set running time threshold within the current cycle; if so, it obtains the task with the longest running time within the current cycle as the third task causing the first task to starve; if not, it obtains the task with the longest running time within the current cycle as the third task causing the first task to starve.

[0065] Furthermore, after monitoring the first task and the corresponding third task, information about both the first and third tasks can be output to trigger a starvation alarm for the first task. The information about the third task includes its identification information, such as its name, thread number, or process ID. Optionally, the information may also include the running time of the third task within the current cycle. It should be noted that the tasks in this embodiment can be system-level or application-level tasks; that is, the first or third task may be either system-level or application-level. The starvation alarm for the first task can be displayed as key information to system or application developers to help them locate system or application problems. It should also be noted that, in addition to issuing a starvation alarm for the first task, a silent restart of the third task can be used to allow the first task to be scheduled, thereby resolving the starvation problem of the first task and achieving the purpose of starving the first task. When the third task is silently restarted, it will release the processor resources it occupies and re-enter the ready state, giving other tasks in the ready state (such as the first task) a chance to be scheduled and solving the task starvation problem.

[0066] In this embodiment, the embedded operating system 201 also supports locking mechanisms to ensure the correctness and / or consistency of operational data in a multi-tasking environment. This embodiment does not limit the types of locks supported by the embedded operating system 201, but includes, but is not limited to, mutexes or spinlocks. A mutex is a simple locking method to control access to shared resources. A mutex has two states: locked and unlocked. If a task locks a shared resource that requires mutual exclusion, other tasks cannot lock the same shared resource until it unlocks it. Spinlocks are also a locking mechanism proposed to protect shared resources. Spinlocks are similar to mutexes; both are used to solve the problem of mutual exclusion of a shared resource. Whether it's a mutex or a spinlock, at any given time, there can be at most one holder, meaning that at any given time, at most one task can acquire the mutex or spinlock. However, mutexes and spinlocks differ slightly in their scheduling mechanisms. For mutexes, if a mutex for a shared resource is already held by a task, other tasks requesting mutexes for that shared resource can only go to sleep. However, spinlocks do not cause other tasks requesting spinlocks for the same shared resource to go to sleep. If a spinlock is already held by another task, the spinlock requester will continuously loop and check whether the holder of the spinlock has released it. Of course, in addition to mutexes and spinlocks, the embedded operating system 201 also supports various other locking mechanisms such as shared locks and fair locks, which will not be detailed here.

[0067] Even with a lock mechanism in place, improper use of the lock mechanism—for example, if a task acquires a lock but forgets to release it due to a code logic error or a system deadlock—can cause other tasks requesting the corresponding lock to time out (i.e., starve) because they cannot acquire the lock. It should be noted that not all locks will cause other tasks requesting the lock to starve. Therefore, in this embodiment, locks that may cause task starvation are referred to as specific locks. Regarding specific locks, in this embodiment, the embedded operating system 201 can also monitor whether a specific lock exists and record its holding time when it is detected; the holding time of a specific lock refers to the length of time the specific lock is occupied or held by the current task. In this embodiment, the length of the holding time of a specific lock indicates whether a deadlock or a task forgetting to release the specific lock has occurred. Based on this, the existence of a target lock can be identified based on the holding time, and if a target lock is identified, a second task requesting the target lock can be obtained, and timeout scheduling can be performed on the second task. A target lock refers to a specific lock that has been occupied by the current task for a long time without being released.

[0068] In an optional embodiment, a lock holding time threshold can be set. If the lock holding time of a specific lock exceeds the set threshold, it indicates that the specific lock may be deadlocked or that a task has forgotten to release the specific lock. Based on this, the embedded operating system 201 can also monitor whether a target lock has a lock holding time exceeding the set threshold. If a target lock with a lock holding time exceeding the set threshold is detected, a second task requesting the target lock is obtained, and timeout scheduling is performed on the second task. In this embodiment, the target lock is a specific lock with a lock holding time exceeding the set threshold; the second task requesting the target lock refers to a task that is starved (or timed out) because it cannot acquire the target lock, so timeout scheduling can be performed on the second task. Furthermore, when the specific lock is released, the lock holding time of the specific lock can be cleared to zero.

[0069] In one optional embodiment, the specific lock includes a mutex and / or a spinlock. In this embodiment, the embedded operating system 201 can also monitor whether a mutex or spinlock occurs, and when a mutex or spinlock is detected, record its holding time; determine whether the holding time of the mutex or spinlock exceeds a set holding time threshold; if so, treat the task requesting the mutex or spinlock as a starved (or timed-out) second task, and perform timeout scheduling for the second task. Furthermore, when the mutex or spinlock is released, its holding time can be cleared to zero. In this embodiment, the value of the holding time threshold is not limited; for example, it can be 10s, 30s, 1 minute, 2 minutes, 5 minutes, etc.

[0070] In this embodiment, the method for timeout scheduling of the second task is the same as or similar to the method for timeout scheduling of the first task, and will only be briefly described here. For a detailed description, please refer to the foregoing embodiments. The method for timeout scheduling of the second task includes: outputting the information of the second task to trigger a starvation alarm for the second task; or, outputting the information of the second task and the information of the task currently holding the target lock to trigger a timeout scheduling alarm (or starvation alarm) for the second task; or, silently restarting the task currently holding the target lock so that the second task can be scheduled, thereby resolving the starvation problem of the second task. The information of the second task includes its identification information, such as the name of the second task, or the thread number or process number corresponding to the second task. The task currently holding the target lock refers to the task that caused the starvation of the second task. The information of this task includes its identification information, such as the name of the task, or the thread number or process number corresponding to the task. Furthermore, the information of the second task may also include the time when the second task requested the target lock; correspondingly, the information of the task currently holding the target lock may also include the time the task held the target lock, i.e., the lock holding time.

[0071] In some optional embodiments of this application, the embedded operating system 201 can, on the one hand, record the readiness time of a task in the ready state and detect whether task starvation has occurred based on the readiness time of the task in the ready state; on the other hand, it can record the lock holding time of a specific lock and detect whether task starvation has occurred based on the lock holding time of the specific lock, thus enabling a more comprehensive detection of task starvation problems in the system. It should be noted that in the embodiments of this application, the execution order of these two detection methods is not limited; the two detection methods can be executed in parallel or sequentially according to a set order. Furthermore, it should be noted that the two detection methods can be used selectively or in combination. In the case of selective use, the detection method based on the readiness time of the task in the ready state to detect whether task starvation has occurred can be used alone, or the detection method based on the lock holding time of a specific lock to detect whether task starvation has occurred can be used alone.

[0072] In addition to using the lock holding time of a specific lock as the sole method for detecting task starvation, the embedded operating system 201 can also monitor for the presence of a specific lock during operation and record its lock holding time when detected. If a target lock is identified based on the specific lock, the task requesting the target lock is obtained, and timeout scheduling is performed on that task. Optionally, a specific lock with a lock holding time greater than a set lock holding time threshold can be used as the target lock. A detailed description of this embodiment can be found in the foregoing embodiments and will not be repeated here.

[0073] It should be noted that in the above embodiments, the embedded operating system 201 is described as the execution subject. However, those skilled in the art should understand that from the perspective of the embedded device 100, the various functions implemented by the embedded operating system 201 are implemented by the processor 101 in the embedded device 100 executing the program code corresponding to the embedded operating system 201 stored in the memory 102. The two are just different ways of describing them.

[0074] In addition to the aforementioned embedded devices, embodiments of this application also provide an embedded operating system, the internal structure of which is as follows: Figure 1b As shown, it includes: a task monitoring module 11b, a readiness time recording module 12b, and a processing module 13b.

[0075] The task monitoring module 11b is used to monitor tasks that transition from a non-ready state to a ready state during the operation of the embedded operating system; the ready time recording module 12b is used to record the ready time of the tasks monitored by the monitoring module 11b when they are in the ready state; and the processing module 13b is used to identify whether a first task exists based on the ready time recorded by the recording module 12b, and to perform timeout scheduling processing on the first task if the first task is identified.

[0076] In an optional embodiment, the aforementioned non-ready state includes at least one of the following: uncreated state, blocked state, running state, and suspended state. Based on this, when monitoring a task transitioning from the non-ready state to the ready state, the task monitoring module 11b may perform at least one of the following operations:

[0077] When a new task is detected, it is determined that the task has entered the ready state from the uncreated state.

[0078] When it is detected that a task in a blocked state has completed its blocking delay, the task is determined to have transitioned from the blocked state to the ready state.

[0079] When it is detected that a running task is preempted by another task, the task is determined to enter the ready state from the running state.

[0080] When a task in a suspended state is awakened by a running task, it is determined that the task has entered the ready state from the suspended state.

[0081] Further optionally, the task monitoring module 11b is also used to: monitor tasks that transition from a ready state to a non-ready state, and when a task transitions from a ready state to a non-ready state is detected, reset the ready time of the task to zero.

[0082] Further optionally, when monitoring a task transitioning from a ready state to a non-ready state, the task monitoring module 11b may perform at least one of the following operations:

[0083] When a task in the ready state is detected to be scheduled, it is determined that the task will transition from the ready state to the running state.

[0084] When it is detected that a task in the ready state is suspended by a running task, it is determined that the task has entered the suspended state from the ready state.

[0085] Further optional, such as Figure 1c As shown, the embedded operating system in this embodiment further includes a runtime recording module 14b and an acquisition module 15b. The runtime recording module 14b is further configured to record the runtime of each task scheduled for execution within a set period. Correspondingly, the acquisition module 15b is configured to, when the processing module 13b identifies the first task, acquire the task whose runtime in the current period is greater than a set runtime threshold or has the longest runtime as the third task causing the first task to time out.

[0086] In an optional embodiment, when processing module 13b performs timeout scheduling processing on the first task, it is specifically used to: output the information of the first task and the information of the third task to trigger a timeout scheduling alarm for the first task; or, silently restart the third task so that the first task can be scheduled.

[0087] Further optional, such as Figure 1c As shown, the embedded operating system in this embodiment further includes a lock monitoring module 16b and a lock occupancy time recording module 17b. The lock monitoring module 16b is used to monitor specific locks during the operation of the embedded operating system; the lock occupancy time recording module 17b is used to record the lock occupancy time of the specific locks monitored by the lock monitoring module 16b; the processing module 13b is also used to: identify whether a target lock exists among the specific locks based on the lock occupancy time, and if a target lock is identified, obtain a second task requesting the target lock, and perform timeout scheduling processing on the second task.

[0088] Further optionally, the lock holding time recording module 17b is also used to: clear the lock holding time of a specific lock to zero when the specific lock is released.

[0089] Further optionally, when processing the second task for timeout scheduling, the processing module 13b is specifically used to: output the information of the second task and the information of the task currently holding the target lock, so as to trigger a timeout alarm for the second task; or, silently restart the task currently holding the target lock so that the second task can be scheduled.

[0090] For a detailed description or implementation process of the operations performed by each module in the aforementioned embedded operating system, please refer to the foregoing embodiments, which will not be repeated here.

[0091] The embedded operating system in this application, when monitoring a task transitioning from a non-ready state to a ready state, records the ready time of that task. The length of the ready time indicates the time during which the task cannot be scheduled. Monitoring whether a task is starving by measuring the time it cannot be scheduled provides higher accuracy and avoids false positives. Furthermore, it can also record the holding time of specific locks and detect whether task starvation has occurred based on the holding time of specific locks, enabling a more comprehensive detection of task starvation problems in the system.

[0092] Furthermore, such as Figure 1d As shown in the illustration, this application embodiment also provides another embedded operating system, which includes: a lock monitoring module 11d, a lock occupancy time recording module 12d, and a processing module 13d. The lock monitoring module 11d is used to monitor a specific lock during the operation of the embedded operating system; the lock occupancy time recording module 12d is used to record the lock occupancy time of the specific lock monitored by the lock monitoring module 11d; the processing module 13d is used to: identify whether a target lock exists among the specific locks based on the lock occupancy time recorded by the lock occupancy time recording module 12d, and, if a target lock is identified, obtain a second task requesting the target lock, and perform timeout scheduling processing on the second task.

[0093] Further optionally, the lock holding time recording module 12d is also used to: clear the lock holding time of a specific lock to zero when the specific lock is released.

[0094] Further optionally, when processing the second task for timeout scheduling, the processing module 13d is specifically used to: output the information of the second task and the information of the task currently holding the target lock, so as to trigger a timeout alarm for the second task; or, silently restart the task currently holding the target lock so that the second task can be scheduled.

[0095] For a detailed description or implementation process of the operations performed by each module in the aforementioned embedded operating system, please refer to the foregoing embodiments, which will not be repeated here.

[0096] The embedded operating system in this application embodiment can record the lock holding time of a specific lock and detect whether a task scheduling timeout (starvation) problem occurs based on the lock holding time of the specific lock, and resolve the task scheduling timeout (starvation) problem in the system through timeout scheduling processing.

[0097] Figure 3a This is a flowchart illustrating an embedded task state detection method provided as an exemplary embodiment of this application. The method is applicable to embedded devices or embedded operating systems, such as... Figure 3a As shown, the method includes:

[0098] 31a. During the operation of the embedded operating system, monitor the task that enters the ready state from the non-ready state and record the ready time of the task in the ready state.

[0099] 32a. If the first task is identified based on the ready time, timeout scheduling is performed on the first task.

[0100] Optionally, identifying the first task based on the readiness time includes: acquiring tasks whose readiness time is greater than a set readiness time threshold, and designating them as the first task.

[0101] Optionally, the non-ready state in this embodiment includes at least one of the following: uncreated state, blocked state, running state, and suspended state; correspondingly, monitoring the task that transitions from the non-ready state to the ready state includes at least one of the following:

[0102] When a new task is detected, it is determined that the task has entered the ready state from the uncreated state.

[0103] When it is detected that a task in a blocked state has completed its blocking delay, the task is determined to have transitioned from the blocked state to the ready state.

[0104] When it is detected that a running task is preempted by another task, the task is determined to enter the ready state from the running state.

[0105] When a task in a suspended state is awakened by a running task, it is determined that the task has entered the ready state from the suspended state.

[0106] In an optional embodiment, the method further includes: monitoring a task that transitions from a ready state to a non-ready state, and resetting the ready time of the task to zero.

[0107] Optionally, monitoring tasks that transition from a ready state to a non-ready state includes at least one of the following:

[0108] When a task in the ready state is detected to be scheduled, it is determined that the task will transition from the ready state to the running state.

[0109] When it is detected that a task in the ready state is suspended by a running task, it is determined that the task has entered the suspended state from the ready state.

[0110] The method in this embodiment can be executed by an operating system in an embedded device or an embedded operating system. This embodiment improves the operating system in the embedded device or the embedded operating system to provide an embedded operating system with task status detection function, solving the problem of task starvation detection at the system level; moreover, it uses the length of time a task is in the ready state to indicate the time during which the task cannot be scheduled, and monitors whether a task is starved by monitoring the time the task cannot be scheduled, which has higher accuracy and avoids false judgments.

[0111] Figure 3b This is a flowchart illustrating another embedded task state detection method provided as an exemplary embodiment of this application. Figure 3b As shown, the method includes:

[0112] 31b. During the operation of the embedded operating system, monitor the task that enters the ready state from the non-ready state and record the ready time of the task in the ready state.

[0113] 32b. During the operation of the embedded operating system, the running time of each task scheduled to be executed in each cycle is recorded according to the set cycle.

[0114] 33b. If the first task is identified based on the readiness time, the task with the longest running time in the current cycle that has a running time greater than a set running time threshold or the task with the longest running time is selected as the third task that causes the first task to starve.

[0115] 34b. Output the information of the first task and the information of the third task to trigger the starvation alarm of the first task; or, silently restart the third task so that the first task can be scheduled.

[0116] For a detailed description of each step, please refer to the foregoing embodiments, which will not be repeated here.

[0117] In this embodiment, a cycle is set, and the execution time of each task scheduled within that cycle is recorded at the cycle level. When a first task is identified, tasks whose execution time in the current cycle exceeds a set execution time threshold are identified as the third task causing the first task to starve. This allows for simultaneous monitoring of which task caused the first task to starve. This triggers a starvation alarm for the first task. In handling the alarm for the first task, not only is the starved first task identified, but the third task causing the starvation is also output. Alternatively, a silent restart of the third task can be used to give the first task a scheduling opportunity, resolving its starvation problem and achieving the goal of starving the first task.

[0118] Figure 3c This is a flowchart illustrating another embedded task state detection method provided as an exemplary embodiment of this application. Figure 3c As shown, the method includes:

[0119] 31c. During the operation of the embedded operating system, monitor the task that enters the ready state from the non-ready state and record the ready time of the task in the ready state.

[0120] 32c. During the operation of the embedded operating system, the running time of each task scheduled to be executed in each cycle is recorded according to the set cycle.

[0121] 33c. If the first task is identified based on the readiness time, the task with the longest running time in the current cycle that has a running time greater than a set running time threshold or the task with the longest running time is selected as the third task that causes the first task to starve.

[0122] 34c. Output the information of the first task and the information of the third task to trigger the starvation alarm of the first task; or, silently restart the third task so that the first task can be scheduled.

[0123] 35c. During the operation of the embedded operating system, a specific lock is detected and the lock holding time of that specific lock is recorded.

[0124] 36c. If the target lock is identified based on the lock holding time, obtain the second task that requests the target lock, and perform timeout scheduling for the second task.

[0125] It should be noted that steps 31c, 32c, and 35c can be executed in parallel or in a certain sequential order. For ease of illustration, in Figure 3c The diagram uses sequential execution as an example, but it is not limited to this.

[0126] Optionally, the specific lock includes a mutex lock and / or a spinlock.

[0127] Optionally, the method further includes: when the specific lock is released, resetting the lock holding time of the specific lock to zero.

[0128] Optionally, timeout scheduling processing is performed on the second task, including: outputting information about the second task and information about the task currently occupying the target lock to trigger a timeout scheduling (starvation) alarm for the second task; or, silently restarting the task currently occupying the target lock so that the second task can be scheduled, thereby resolving the starvation problem of the second task.

[0129] In this embodiment, on the one hand, the ready time of a task in the ready state can be recorded, and the ready time of a task in the ready state can be used to detect whether a task starvation occurs because it cannot be scheduled. On the other hand, the holding time of a specific lock can be recorded, and the holding time of a specific lock can be used to detect whether a task starvation occurs due to deadlock or the task holding the specific lock forgets to release the lock. This allows for a more comprehensive detection of task starvation problems in the system.

[0130] Figure 4 This is a flowchart illustrating another embedded task state detection method provided as an exemplary embodiment of this application. Figure 4As shown, the method includes:

[0131] 41. During the operation of the embedded operating system, a specific lock is monitored and the lock holding time of the specific lock is recorded;

[0132] 42. If the target lock is identified based on the lock holding time, obtain the second task that requests the target lock, and perform timeout scheduling for the second task.

[0133] Optionally, the specific lock includes a mutex lock and / or a spinlock.

[0134] Optionally, the method further includes: resetting the lock holding time of the specific lock to zero when the specific lock is released.

[0135] Optionally, timeout scheduling processing is performed on the second task, including: outputting information about the second task and information about the task currently occupying the target lock to trigger a timeout scheduling (starvation) alarm for the second task; or, silently restarting the task currently occupying the target lock so that the second task can be scheduled, thereby resolving the starvation problem of the second task.

[0136] In this embodiment, by recording the holding time of a specific lock and detecting whether there is a task starvation problem caused by deadlock or the task holding the specific lock forgetting to release the lock, the task starvation problem in the system can be detected more comprehensively.

[0137] It should be noted that the execution subject of each step in the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 41 to 42 can be device A; or the execution subject of step 41 can be device A, and the execution subject of step 42 can be device B; and so on.

[0138] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 41, 42, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0139] In addition to the above-described device and method embodiments, this application also provides a computer-readable storage medium storing program code corresponding to an embedded operating system, wherein the program code corresponding to the embedded operating system can implement the steps in the above-described method embodiments when executed.

[0140] It should be noted that the technical solutions provided in this application are applicable not only to embedded devices but also to any non-embedded device containing a non-embedded operating system (hereinafter referred to as the operating system). By improving the operating system in the non-embedded device, an operating system with task status detection function is provided, solving the task starvation detection problem at the system level. The non-embedded device can be various devices such as mobile phones, tablets, laptops, or servers. This application can also provide a non-embedded device capable of solving the task starvation problem, and a task status detection method executed by the non-embedded device (specifically, the operating system in the non-embedded device). The process of this task status detection method is briefly described below from the perspective of a non-embedded device.

[0141] For non-embedded devices, the structure is similar, also including hardware and software subsystems. The difference lies in that the modules or components within both the hardware and software subsystems of a non-embedded device are non-embedded. The software subsystem of a non-embedded device includes a non-embedded operating system. This non-embedded operating system is system software responsible for controlling and managing various hardware and software resources of the non-embedded device, such as hardware drivers, memory management, and task management. The program code corresponding to this non-embedded operating system is stored in the memory of the hardware subsystem. During the startup or normal operation of the non-embedded device, the processor in its hardware subsystem can load the program code corresponding to the operating system stored in memory to implement various control or driver functions of the operating system, thereby successfully starting the non-embedded device or ensuring its normal operation.

[0142] In this embodiment, the non-embedded operating system in the non-embedded device, in addition to traditional task management functions, can also detect task status, identify task starvation, and handle starved tasks accordingly. Specifically, the processor executes the operating system's corresponding program code stored in memory, which can implement traditional task management functions as well as various functions related to task status detection. The working principle of the non-embedded operating system in the non-embedded device will be explained in detail below, focusing on task management:

[0143] Task management is a primary function of non-embedded operating systems. In this embodiment, task management includes, but is not limited to, task creation, task deletion, task scheduling, changing task priority, and task status detection. In this embodiment, tasks in non-embedded devices have the following states: Ready, Running, Blocked, and Suspended. Tasks transition between these states, and the transition relationships between task states are as follows: Figure 2 As shown. For detailed explanations of these states, please refer to the foregoing embodiments, which will not be repeated here.

[0144] In this embodiment, the non-embedded operating system can monitor whether any tasks transition from a non-ready state to a ready state during operation. When a task transitions from a non-ready state to a ready state, it begins to calculate and record the ready time of that task. For any given task, its ready time can directly reflect whether the task is in a starved state. Therefore, based on the ready time, it is possible to identify whether a first task exists among the ready tasks, and if the first task is identified, timeout scheduling processing can be performed on it.

[0145] In an optional embodiment, a ready time threshold can be set. If the ready time of a task is greater than the set ready time threshold, it indicates that the task has not been scheduled for a long time and is in a starved state. Conversely, if the ready time of a task is less than or equal to the set ready time threshold, it indicates that the task has not been waiting for scheduling for a long time and is not in a starved state, and can continue to wait for scheduling. Based on this, it is also possible to monitor whether there are tasks with ready times greater than the set ready time threshold. If there are tasks with ready times greater than the set ready time threshold, it can be determined that the task is starved, and timeout scheduling is performed on the task to promptly resolve various abnormal situations caused by task starvation. For ease of description and distinction, in this embodiment, the task with a ready time greater than the set ready time threshold is referred to as the first task. The first task can be any task in the ready state, and its number can be one or more. In this embodiment, the value of the ready time threshold is not limited, for example, it can be 10s, 30s, 1 minute, 2 minutes, 5 minutes, etc.

[0146] In this embodiment, monitoring a task that transitions from a non-ready state to a ready state includes at least one of the following:

[0147] When a new task is detected, it is determined that the new task will enter the ready state from the uncreated state.

[0148] When a task in a blocked state is detected to have its blocking delay ended, it is determined that the task in the blocked state can enter the ready state from the blocked state.

[0149] When it is detected that a running task is preempted by another task, it is determined that the running task can transition from the running state to the ready state.

[0150] When a task in a suspended state is awakened by a running task, it is determined that the suspended task can transition from the suspended state to the ready state.

[0151] Optionally, the non-embedded operating system will also monitor tasks transitioning from the ready state to the non-ready state and reset the task's ready time to zero to ensure that the ready time accurately reflects the duration the task has been waiting for scheduling. Monitoring tasks transitioning from the ready state to the non-ready state includes at least one of the following:

[0152] When a task in the ready state is detected to be scheduled, determine that the task in the ready state will enter the running state.

[0153] When a task in the ready state is suspended by a running task, it is determined that the task in the ready state will enter the suspended state.

[0154] Furthermore, in an optional embodiment of this application, a period can be set. The non-embedded operating system can record the running time of each scheduled task within each period, using the period as the granularity. At the end of each period, the recorded running time of each scheduled task within that period can be cleared to allow for re-recording of the running time in the next period. Furthermore, when a first task is identified, the operating system can identify tasks whose running time in the current period exceeds a set running time threshold as the third task causing the first task to starve. After identifying the first task and the corresponding third task, information about both the first and third tasks can be output to trigger a starvation alarm for the first task. Alternatively, a silent restart of the third task can be used to schedule the first task, thus resolving the starvation problem of the first task and achieving the goal of starving the first task.

[0155] Furthermore, in this embodiment, the non-embedded operating system also supports locking mechanisms to ensure the correctness and / or consistency of operational data in a multi-tasking environment. This embodiment does not limit the types of locks supported by the non-embedded operating system, including but not limited to mutexes or spin locks. Even with a supporting locking mechanism, improper use—for example, a task forgetting to release the lock after acquiring it due to a code logic error or a system deadlock—can cause other tasks requiring the corresponding locks to starve. It should be noted that not all locks will cause other tasks requesting locks to starve; therefore, in this embodiment, locks that may cause task starvation are referred to as specific locks. Regarding specific locks, in this embodiment, the non-embedded operating system can also monitor for the presence of specific locks and record the lock holding time when a specific lock is detected. If the lock holding time exceeds a set lock holding time threshold for the target lock, it indicates that the specific lock may be deadlocked or a task may have forgotten to release the specific lock. Therefore, the target lock can be identified based on the lock holding time, and upon identification, a second task requesting the target lock can be obtained, and timeout scheduling can be performed on the second task. Optionally, a specific lock whose holding time is greater than a set holding time threshold can be selected as the target lock. Furthermore, when a specific lock is released, its holding time can be reset to zero.

[0156] In non-embedded devices, the non-embedded operating system can, on the one hand, record the readiness time of a task in the ready state and detect whether task starvation has occurred based on this time; on the other hand, it can record the lock holding time of a specific lock and detect whether task starvation has occurred based on this time. This allows for a more comprehensive detection of task starvation issues in the system. It should be noted that in this embodiment, the execution order of these two detection methods is not limited; they can be executed in parallel or sequentially according to a set order. Furthermore, the two detection methods can be used individually or in combination. When using one method at a time, the method based on the task's readiness time or the method based on the lock holding time of a specific lock can be used alone to detect whether task starvation has occurred.

[0157] The above-described task status detection scheme applied to non-embedded devices, wherein the definition of relevant parameters or the detailed description of operation steps are the same as or similar to the detailed description of the corresponding definition or operation steps applied to embedded devices, can be found in the aforementioned embodiments, and will not be repeated here.

[0158] In addition to the above-mentioned task status detection method, this application also provides a non-embedded operating system, including: a task monitoring module, a readiness time recording module, and a processing module.

[0159] The system includes a task monitoring module for monitoring tasks that transition from a non-ready state to a ready state during the operation of a non-embedded operating system; a ready time recording module for recording the ready time of the task in the ready state; and a processing module for performing timeout scheduling processing on the first task when the first task is identified based on the ready time.

[0160] In an optional embodiment, the aforementioned non-ready state includes at least one of the following: uncreated state, blocked state, running state, and suspended state. Based on this, when monitoring a task transitioning from a non-ready state to a ready state, the task monitoring module may perform at least one of the following operations:

[0161] When a new task is detected, it is determined that the task has entered the ready state from the uncreated state.

[0162] When it is detected that a task in a blocked state has completed its blocking delay, the task is determined to have transitioned from the blocked state to the ready state.

[0163] When it is detected that a running task is preempted by another task, the task is determined to enter the ready state from the running state.

[0164] When a task in a suspended state is awakened by a running task, it is determined that the task has entered the ready state from the suspended state.

[0165] Further optionally, the task monitoring module is also used to: monitor tasks that transition from a ready state to a non-ready state, and when a task transitions from a ready state to a non-ready state is detected, reset the ready time of the task to zero.

[0166] Further optionally, when monitoring a task transitioning from a ready state to a non-ready state, the task monitoring module may perform at least one of the following operations:

[0167] When a task in the ready state is detected to be scheduled, it is determined that the task will transition from the ready state to the running state.

[0168] When it is detected that a task in the ready state is suspended by a running task, it is determined that the task has entered the suspended state from the ready state.

[0169] Optionally, the non-embedded operating system in this embodiment further includes a runtime recording module and an acquisition module. The runtime recording module is further configured to record the runtime of each task scheduled for execution within a set period. Correspondingly, the acquisition module is configured to, when the processing module identifies the first task, acquire the task whose runtime in the current period is greater than a set runtime threshold or has the longest runtime as the third task causing the first task to time out.

[0170] In an optional embodiment, when the processing module performs timeout scheduling processing on the first task, it is specifically used to: output the information of the first task and the information of the third task to trigger a timeout scheduling alarm for the first task; or, silently restart the third task so that the first task can be scheduled.

[0171] Furthermore, this application also provides another non-embedded operating system, including: a lock monitoring module, a lock holding time recording module, and a processing module.

[0172] The lock monitoring module is used to monitor specific locks during the operation of a non-embedded operating system; the lock holding time recording module is used to record the lock holding time of the specific lock; and the processing module is used to obtain the task requesting the target lock when the target lock is identified based on the lock holding time, and to perform timeout scheduling processing on the task.

[0173] Further optionally, the lock holding time recording module is also used to: clear the lock holding time of a specific lock to zero when the specific lock is released.

[0174] Further optionally, when the processing module performs timeout scheduling processing on the second task, it is specifically used to: output the information of the second task and the information of the task currently holding the target lock, so as to trigger a timeout alarm for the second task; or, silently restart the task currently holding the target lock so that the second task can be scheduled.

[0175] For a detailed description or implementation process of the operations performed by each module in the two non-embedded operating systems mentioned above, please refer to the foregoing embodiments, which will not be repeated here.

[0176] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0177] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0178] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0179] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0180] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0181] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0182] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0183] It should also be noted that 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 limitation, 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.

[0184] 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 state detection method for an embedded task, characterized in that, include: During the operation of the embedded operating system, if a task is detected to have transitioned from a ready state to a non-ready state, the ready time of that task is reset to zero. The system monitors tasks that transition from a non-ready state to a ready state and records the time when the task is in the ready state. Record the running time of each task scheduled for execution within each set period. At the end of each cycle, the running time of each scheduled task recorded in that cycle is cleared to zero so that the running time of the scheduled tasks can be recorded again in the next cycle. When a first task with a ready time greater than a set ready time threshold is identified, the task with the longest running time in the current period that has a running time greater than the set running time threshold or the longest running time is selected as the third task that causes the first task to time out and be scheduled. The information of the first task and the information of the third task are output to trigger a timeout scheduling alarm for the first task and the third task is silently restarted so that the first task can be scheduled. The information of the first task includes the ready time of the first task in the ready state, and the information of the third task includes the running time of the third task in the current period.

2. The method according to claim 1, characterized in that, The non-ready state includes at least one of the following: uncreated state, blocked state, running state, and suspended state.

3. The method according to claim 1, characterized in that, The task that is detected to transition from a non-ready state to a ready state includes at least one of the following: When a new task is detected, it is determined that the task has entered the ready state from the uncreated state. When it is detected that a task in a blocked state has completed its blocking delay, the task is determined to have transitioned from the blocked state to the ready state. When it is detected that a running task is preempted by another task, the task is determined to enter the ready state from the running state. When a task in a suspended state is awakened by a running task, it is determined that the task has entered the ready state from the suspended state.

4. The method according to claim 1, characterized in that, Tasks that are monitored to transition from a ready state to a non-ready state include at least one of the following: When a task in the ready state is detected to be scheduled, it is determined that the task will transition from the ready state to the running state. When it is detected that a task in the ready state is suspended by a running task, it is determined that the task has entered the suspended state from the ready state.

5. The method according to any one of claims 1-4, characterized in that, Also includes: A specific lock was detected during the operation of the embedded operating system; Record the lock holding time of the specific lock; If a target lock is identified based on the lock holding time, a second task requesting the target lock is obtained, and timeout scheduling is performed on the second task.

6. The method according to claim 5, characterized in that, The specific locks include mutex locks and / or spinlocks.

7. The method according to claim 5, characterized in that, Also includes: When the specific lock is released, the lock holding time of the specific lock is reset to zero.

8. The method according to claim 5, characterized in that, Timeout scheduling for the second task includes: Output the information of the second task and the information of the task currently occupying the target lock to trigger a timeout scheduling alarm for the second task; or Silently restart the task currently holding the target lock so that the second task can be scheduled.

9. An embedded operating system, characterized in that, include: The task monitoring module is used to monitor tasks that transition from a ready state to a non-ready state during the operation of the embedded operating system, and to reset the ready time of the task to zero. The task that transitioned from a non-ready state to a ready state was monitored; The readiness time recording module is used to record the readiness time of the task when it is in the ready state; as well as The processing module is used to record the running time of each scheduled task in each set period according to the set period; at the end of each period, the running time of each scheduled task in that period is cleared to zero so that the running time of the scheduled task can be recorded again in the next period. When a first task with a ready time greater than a set ready time threshold is identified, the task with the longest running time in the current period that has a running time greater than the set running time threshold or the longest running time is selected as the third task that causes the first task to time out and be scheduled. The information of the first task and the information of the third task are output to trigger a timeout scheduling alarm for the first task and the third task is silently restarted so that the first task can be scheduled. The information of the first task includes the ready time of the first task in the ready state, and the information of the third task includes the running time of the third task in the current period.

10. An embedded device, characterized in that, include: Memory and processor; The memory stores the program code corresponding to the embedded operating system; The processor is coupled to the memory and is used to execute program code corresponding to the embedded operating system, for the purpose of: During the operation of the embedded operating system, when a task is detected to transition from a ready state to a non-ready state, the ready time of the task is reset to zero; when a task is detected to transition from a non-ready state to a ready state, the ready time of the task in the ready state is recorded. During the operation of the embedded operating system, the running time of each scheduled task in each cycle is recorded according to the set cycle. At the end of each cycle, the running time of each scheduled task in that cycle is cleared to zero so that the running time of the scheduled task can be recorded again in the next cycle. as well as When a first task with a ready time greater than a set ready time threshold is identified, the task with the longest running time in the current period that is longer than the set running time threshold is selected as the third task that causes the first task to time out and be scheduled. The information of the first task and the information of the third task are output to trigger a timeout scheduling alarm for the first task and the third task is silently restarted so that the first task can be scheduled. The information of the first task includes the ready time when the first task is in the ready state, and the information of the third task includes the running time of the third task in the current period.

11. The device according to any one of claims 10, characterized in that, The processor is also used for: A specific lock was detected during the operation of the embedded operating system; Record the lock holding time of the specific lock; If a target lock is identified based on the lock holding time, a second task requesting the target lock is obtained, and timeout scheduling is performed on the second task.

12. A computer-readable storage medium storing program code corresponding to an embedded operating system, characterized in that, When the program code corresponding to the embedded operating system is executed by the processor, the processor performs the steps of the method according to any one of claims 1-8.

13. A task status detection method, characterized in that, include: During the operation of a non-embedded operating system, if a task is detected to transition from a ready state to a non-ready state, the ready time of that task is reset to zero. The system monitors tasks that transition from a non-ready state to a ready state and records the time when the task is in the ready state. According to the set cycle, the running time of each scheduled task in each cycle is recorded; at the end of each cycle, the running time of each scheduled task in that cycle is cleared to zero so that the running time of the scheduled task can be recorded again in the next cycle. When a first task with a ready time greater than a set ready time threshold is identified, the task with the longest running time in the current period that has a running time greater than the set running time threshold or the longest running time is selected as the third task that causes the first task to time out and be scheduled. The information of the first task and the information of the third task are output to trigger a timeout scheduling alarm for the first task and the third task is silently restarted so that the first task can be scheduled. The information of the first task includes the ready time of the first task in the ready state, and the information of the third task includes the running time of the third task in the current period.

14. The method according to claim 13, characterized in that, Also includes: During the operation of a non-embedded operating system, a specific lock is monitored, and the lock holding time of the specific lock is recorded; If a target lock is identified based on the lock holding time, a second task requesting the target lock is obtained, and timeout scheduling is performed on the second task.

15. A non-embedded operating system, characterized in that, include: The task monitoring module is used to monitor tasks that transition from a ready state to a non-ready state during the operation of a non-embedded operating system, and to reset the ready time of the task to zero; and to monitor tasks that transition from a non-ready state to a ready state. The readiness time recording module is used to record the readiness time of the task when it is in the ready state; as well as The processing module is used to record the running time of each scheduled task in each set period according to the set period; at the end of each period, the running time of each scheduled task in that period is cleared to zero so that the running time of the scheduled task can be recorded again in the next period. When a first task with a ready time greater than a set ready time threshold is identified, the task with the longest running time in the current period that has a running time greater than the set running time threshold or the longest running time is selected as the third task that causes the first task to time out and be scheduled. The information of the first task and the information of the third task are output to trigger a timeout scheduling alarm for the first task and the third task is silently restarted so that the first task can be scheduled. The information of the first task includes the ready time of the first task in the ready state, and the information of the third task includes the running time of the third task in the current period.

Images