Thread scheduling method and device, electronic equipment and storage medium

Abstract

The invention discloses a thread scheduling method and device, electronic equipment and a storage medium, and belongs to the technical field of electronics. The method comprises the steps that under the condition that a foreground thread of a foreground thread queue is operated, if a first condition is met, a background thread is operated; the foreground thread queue comprises at least one foreground thread; wherein the first condition comprises one of the following items: the waiting duration of the background thread is greater than or equal to a first threshold value; and ending the operation of each foreground thread of the foreground thread queue.

Description

Technical Field

[0001] This application belongs to the field of electronic technology, specifically relating to a thread scheduling method, device, electronic device, and storage medium. Background Technology

[0002] As system operations become more complex and functionally diverse, a large number of threads with varying functions exist within the system to meet different business needs. For example, there are high-priority foreground threads and low-priority background threads. Typically, the Central Processing Unit (CPU) scheduling mechanism can allocate corresponding CPU time slices to all running foreground and background threads within the same scheduling cycle.

[0003] Specifically, since electronic devices typically need to run multiple threads simultaneously, and a CPU core can only execute one thread at any given time, the operating system can quickly switch the context of all running threads in each scheduling cycle, allocating corresponding CPU time slices to all running foreground and background threads so that they can run in the order of allocation. This allows users to have the illusion that "multiple threads are running at the same time".

[0004] However, in the above method, the CPU switches between foreground and background threads, which causes the CPU time slice of the foreground thread to be preempted by the background thread, resulting in less CPU time for the foreground thread. This may cause the foreground application to lag. At the same time, frequent switching between foreground and background threads will lead to excessive CPU overhead, thus degrading system smoothness. Summary of the Invention

[0005] The purpose of this application is to provide a thread scheduling method, apparatus, electronic device, and storage medium that can improve system smoothness.

[0006] In a first aspect, embodiments of this application provide a thread scheduling method, which includes: when running foreground threads in a foreground thread queue, running background threads if a first condition is met; the foreground thread queue includes at least one foreground thread; wherein the first condition includes one of the following: the waiting time of the background thread is greater than or equal to a first threshold; and each foreground thread in the foreground thread queue has finished running.

[0007] Secondly, embodiments of this application provide a thread scheduling device, which includes: a running module; a running model, used to run background threads when a foreground thread in a foreground thread queue is running, if a first condition is met; the foreground thread queue includes at least one foreground thread; wherein the first condition includes one of the following: the waiting time of the background thread is greater than or equal to a first threshold; and each foreground thread in the foreground thread queue has finished running.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a computer program / program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0012] In this embodiment, when running foreground threads in the foreground thread queue, a background thread is run if a first condition is met. The foreground thread queue includes at least one foreground thread. The first condition includes one of the following: the waiting time of the background thread is greater than or equal to a first threshold; or all foreground threads in the foreground thread queue have finished running. In this solution, if the waiting time of the background thread is greater than or equal to a preset threshold, the electronic device can run the background thread. Alternatively, after all foreground threads in the foreground thread queue have finished running, the electronic device can run the background thread in the background thread queue. That is, the electronic device can dynamically control the scheduling timing of background threads, thereby reducing or avoiding the preemption of CPU resources by background threads on foreground threads, ensuring that foreground threads can obtain CPU resources more effectively, and reducing the risk of stuttering in foreground applications running on the electronic device. At the same time, since background threads only have the opportunity to run when the condition is met, the high-frequency invalid running of background threads can be reduced, and the number of switching between foreground and background threads can be reduced, thereby reducing the CPU overhead caused by frequent context switching and improving system smoothness. Attached Figure Description

[0013] Figure 1A This is a schematic diagram of the running queue and threads in related technologies;

[0014] Figure 1B This is a priority diagram of the run queue in related technologies;

[0015] Figure 1C This is a schematic diagram of a red-black tree in related technologies;

[0016] Figure 2A This is one of the schematic diagrams illustrating the execution cycle of a thread in related technologies;

[0017] Figure 2B This is a schematic diagram of CPU load in related technologies;

[0018] Figure 2C This is the second illustration of the thread's execution cycle in related technologies;

[0019] Figure 3 This is one of the flowcharts of a thread scheduling method provided in the embodiments of this application;

[0020] Figure 4 This is a priority diagram of a running queue provided in an embodiment of this application;

[0021] Figure 5 This is a second flowchart of a thread scheduling method provided in an embodiment of this application;

[0022] Figure 6 This is the third flowchart of a thread scheduling method provided in the embodiments of this application;

[0023] Figure 7A This is one of the schematic diagrams of CPU load provided in the embodiments of this application;

[0024] Figure 7B This is a second schematic diagram of CPU load provided in an embodiment of this application;

[0025] Figure 7C This is the third schematic diagram of CPU load provided in the embodiments of this application;

[0026] Figure 8 This is the fourth flowchart of a thread scheduling method provided in the embodiments of this application;

[0027] Figure 9 This is a schematic diagram of the structure of a thread scheduling device provided in an embodiment of this application;

[0028] Figure 10 This is one of the hardware structure diagrams of an electronic device provided in the embodiments of this application;

[0029] Figure 11 This is a second schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0031] The terms "first," "second," etc., used in this application's specification are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects. For example, a first object can be one or more, where "more" means at least two. Furthermore, in the specification, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0032] The terms "at least one," "at least one," etc., used in this application's specification refer to any one, any two, or a combination of two or more of the included objects. For example, "at least one of a, b, and c" can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple, and multiple means at least two. Similarly, "at least two" refers to two or more, and its meaning is similar to that of "at least one."

[0033] The terminology used in the implementation section of this application is only for explaining specific embodiments of this application and is not intended to limit this application. The terminology involved in the embodiments of this application is explained below.

[0034] A thread is the basic unit of scheduling and resource allocation by the operating system; it is an execution unit within a process. It allows multiple tasks to be executed concurrently within a single process, thereby improving program concurrency and responsiveness. A process is the smallest unit of resource allocation, possessing its own memory space, file handles, etc. A thread is the smallest unit of CPU scheduling; it can share the resources of a process, such as memory and files, but has its own independent stack and program counter.

[0035] Threads can be mainly divided into two categories: high-priority foreground threads and low-priority background threads. High-priority foreground threads ensure smooth application operation and user interaction, requiring timely responses; low-priority background threads provide basic support for the system or application, such as data synchronization and log collection, with lower real-time requirements.

[0036] In the field of operating system scheduling, the time window is a core concept used to describe the time range or policy framework for the scheduler to allocate CPU resources. Different scheduling classes, such as real-time scheduling and completely fair scheduling, have significantly different definitions and utilization methods for the time window, and its design directly affects the system's response speed, fairness, and throughput.

[0037] Run queue (rq): A structure containing all processes or threads in a ready state, waiting for CPU resources to execute. It determines which tasks can be executed by the CPU immediately. Different scheduling policies are implemented differently, but the core goal is the same: to efficiently select the next task to run, while ensuring fairness or real-time performance.

[0038] like Figure 1A As shown, each run queue (rq) can contain many threads. Electronic devices can add threads to different run queues (rq) based on their urgency. For example... Figure 1B As shown, common request queues (RQs) are ranked from highest to lowest priority as follows: Deadline RQ, Real Time (RT) RQ, Completely Fair Scheduler (CFS) RQ, and Idle RQ.

[0039] Deadline queues (RDQs) have the highest priority and primarily run tasks with strict deadlines. These tasks must be completed within the specified timeframe, otherwise system failure may occur. Deadline queue scheduling policies include: SCHED_DEADLINE (scheduled by deadline, prioritizing tasks with the closest deadlines); SCHED_FIFO (first-come, first-served for tasks with the same priority, allowing higher-priority tasks to preempt lower-priority tasks); and SCHED_RR (tasks with the same priority run in a round-robin fashion, allowing higher-priority tasks to preempt lower-priority tasks).

[0040] RT RQ's task type is real-time task, which has strict time requirements and must be completed within a specified time, such as application rendering tasks and main thread tasks. Its scheduling strategy uses priority queue management, sorting tasks according to their real-time priority.

[0041] The CFS rq runs normal tasks, including user-space processes and kernel threads. All tasks compete for CPU time within a unified CFS rq. Scheduling is based on the task's virtual runtime (vruntime), with fairness achieved through a red-black tree algorithm. Each task independently calculates its vruntime and participates in the competition. Its design goal is to provide nearly equal CPU access opportunities for all runnable threads, making it particularly suitable for multi-tasking desktop environments, server loads, and general computing scenarios.

[0042] Idle rq is a special design primarily used for task scheduling of idle CPUs. Each CPU has only one idle task, which is used to execute low-power related algorithms, allowing the CPU to enter different levels of idle states in order to save power.

[0043] A red-black tree is a self-balancing binary search tree that can perform operations such as searching, adding, and deleting in O(logN) time. For example... Figure 1C As shown, in a red-black tree, each node represents a thread, and the value within the node represents the virtual runtime (vruntime) of each thread. Each scheduling operation selects the thread from the leftmost leaf node of the red-black tree with the smallest vruntime. As the system time progresses, threads that previously ran on the left will gradually move to the right side of the red-black tree, and threads that were originally on the right will eventually move to the left. Therefore, every thread in a red-black tree has a chance to run, ensuring fairness.

[0044] It should be noted that, in Figure 1C In the red-black tree shown, the nodes with values ​​of 27, 7, 25, 31, and 62 are black, and the nodes with values ​​of 19, 34, 2, 49, and 98 are red.

[0045] The virtual runtime of a red-black tree is calculated using the following formula (1):

[0046] (1)

[0047] Here, NICE_0_LOAD is the base weight, usually NICE_0_LOAD=1024, which can represent the weight of a process with a nice value of 0; actual running time can represent the actual time the process runs on the CPU; thread weight can be determined by the current thread's priority nice, for example, weight=1024 / (1.25^nice).

[0048] For example, suppose there are two threads, such as thread A with a thread weight of 512 and thread B with a thread weight of 256, and the actual running time of both thread A and thread B is 1 second. Then, after thread A runs for 1 second, the virtual runtime of thread A is vruntime_A = 1 × 1024 / 512 = 2; after thread B runs for 1 second, the virtual runtime of thread B is vruntime_B = 1 × 1024 / 256 = 4. At this time, the electronic device can select thread A, which has a smaller virtual runtime and a larger weight, to run, based on the logic of selecting the thread with the smallest virtual runtime.

[0049] Control groups (cgroups) are a kernel mechanism that allows processes to be organized into hierarchical groups and each group to be allocated specific resource quotas. They are used to limit, isolate, and track the resource usage of process groups, such as CPU, memory, and I / O. Their core objectives are: resource limiting to prevent a process group from exhausting system resources; resource isolation to ensure that resource usage between different groups does not interfere with each other; and resource tracking to monitor and record the resource consumption of each group. Typically, multiple cgroups exist in a system, such as top-app groups, foreground groups, and background groups.

[0050] The Top-App Group typically comprises the most important or resource-intensive application groups in the system, such as critical business services, high-performance computing tasks, and core applications that users interact with directly. It is the highest priority group for system resource allocation.

[0051] The Foreground Group includes foreground services or applications that are not top-level but still need to remain active, such as desktop applications, interactive command-line tools, and real-time user-responsive services. Specifically, examples include background playback in music players, background navigation in navigation apps, and download services.

[0052] The Background Group includes non-critical, low-priority tasks such as logging, data backup, and cleanup; periodic maintenance tasks such as system update checks; and resource-intensive but non-real-time tasks such as compilation and video transcoding.

[0053] Thread starvation is a phenomenon in multithreaded programming where some threads are unable to acquire necessary resources, such as CPU time, locks, and input / output (I / O), due to unfair resource allocation or unreasonable scheduling strategies, thus preventing tasks from progressing normally.

[0054] In computer systems, I / O is the process of transferring data between the computer and external devices, such as disks, networks, keyboards, and monitors. I / O operations are one of the key bottlenecks in system performance, especially in multithreaded environments. Improper I / O handling can lead to thread starvation, resource contention, or decreased system throughput.

[0055] Utilization Clamping (Uclamp) is a feature of the Linux kernel scheduler that allows you to set the current, minimum, or maximum percentage of load for a thread or CPU. The value ranges from 0 to 100%, which means that user space or the system can limit the CPU utilization of a thread by setting two parameters.

[0056] Uclamp_min: Guarantees the lowest possible percentage of load on threads or the CPU;

[0057] Uclamp_max: Guarantees the maximum percentage of load on a thread or CPU.

[0058] Load refers to the load calculated using the WALT (Window-Assisted Load Tracking) or PELT (Per-Entity Load Tracking) algorithms, normalized based on the computing power and frequency differences of different CPUs. The WALT algorithm will be used as an example to illustrate how load is calculated.

[0059] The WALT algorithm is a novel algorithm that tracks process CPU utilization in units of time windows (window-based view of time) and calculates the runtime of the next window. The CPU runtime within a statistical window calculated using the WALT algorithm can be called the WALT time, or WALTCPU runtime. The time window is a configurable value, with a default value of 20 milliseconds. The formula for calculating the WALT time is as follows (Formula 2):

[0060] (2)

[0061] Among them, delta can be used to represent the running time of a process in each time window; cur_freq can be used to identify the current operating frequency of the CPU; max_freq can be used to represent the maximum frequency of all CPUs in the current system; cur_IPC can be used to represent the current computing power of the CPU; and max_IPC can be used to represent the maximum computing power of all CPUs in the current system.

[0062] For example, suppose in a big.LITTLE ARM SoC, the maximum frequency of the small core CPU is 1 GHz, the maximum frequency of the big core CPU is 3 GHz, and the computing power (IPC) of the big core is twice that of the small core. Then, the time it takes for the big core to run at its maximum frequency for a statistical window is called the 100% WALT CPU time, which is 20 ms. When the small core CPU runs at 1 GHz for 10 ms, its WALT CPU time can be calculated using the formula (2) above. That is, although it runs at 1 GHz for 10 ms on the small core CPU, according to the WALT algorithm, it is equivalent to running for only 1.67 ms, i.e., 1.67 ms = 10 ms × (1 / 3) × (1 / 2). Here, 10 ms means the small core runs at 1 GHz, 1 in (1 / 3) represents the frequency of the small core 1 GHz, and 3 represents the frequency of the big core 3 GHz, i.e., the maximum frequency of the big core is three times that of the small core; (1 / 2) can represent that the IPC of the big core is twice that of the small core.

[0063] After the WALTCPU runtime is calculated based on the WALT algorithm, the electronic device can calculate the load Load_avg based on the following formula (3).

[0064] (3)

[0065] Load_avg can be used to represent the CPU load calculated using the WALT algorithm; Windows can be used to represent the time window for the WALT algorithm calculation, with a default value of 20ms; 1024 can be used to normalize the calculation result to 1024 to unify the calculation unit.

[0066] CPU frequency (Clock Frequency) is the number of clock cycles per second that a CPU core executes, measured in Hz (e.g., GHz). A higher frequency allows for the execution of more instructions per unit of time. The relationship between CPU frequency and load (Load_avg) is shown in Table 1 below. Knowing the load_avg, you can look up the corresponding CPU frequency in Table 1.

[0067] Table 1

[0068] CPU frequency Load (Load_avg) 3GHz 1024 2.5GHz 950 2Ghz 850 1.8GHz 680 1.5GHz 600 1.2GHz 550 1Ghz 480 0.8GHz 450

[0069] As system business becomes more complex and functions more diverse, a large number of threads with different functions exist in the system to meet different business needs. For example, there are high-priority foreground threads and low-priority background threads.

[0070] In the current CPU scheduling mechanism, although the system can differentiate threads by priority, such as determining the execution order and time slice allocation of multiple threads, within the same scheduling cycle, it allocates corresponding CPU time slices to all running foreground and background threads. Figure 2A As shown, assuming the currently running threads include 3 foreground threads and 1 background thread, namely foreground thread A, foreground thread B, and foreground thread C, and background thread 1, the system can allocate CPU time slices to foreground thread A, foreground thread B, background thread 1, and foreground thread C in the first scheduling window, and then allocate CPU time slices to foreground thread C, background thread 1, foreground thread A, and foreground thread B in the second scheduling cycle. The height of each thread represents its corresponding CPU load.

[0071] In this system, most threads are normal threads using the CFS (Constant Forward) scheduling algorithm. While CFS prioritizes foreground and background threads to ensure foreground threads are scheduled first, to ensure complete fairness, background threads that are not scheduled are given higher priority. This can lead to background threads preempting CPU resources from foreground threads when they run within the same scheduling cycle, thus impacting foreground thread execution time. Current priority mechanisms adjust CPU time slice allocation to balance the time between foreground and background threads when they run within the same scheduling cycle. However, this still doesn't solve the problem of redundant background thread scheduling, resulting in insufficient granularity in system scheduling.

[0072] In addition, combined Figure 2A If the system runs background thread 1 during an unnecessary period when CPU resources are scarce, then... Figure 2B As shown, background thread 1 will increase the CPU load, causing the CPU to run at a high frequency, wasting computing resources and reducing CPU energy consumption. This results in the CPU running at an inefficient high frequency. Meanwhile, as... Figure 2C As shown, since each scheduling cycle requires scheduling of foreground threads ABC and background thread 1, frequent context switching of threads will occur.

[0073] Because modern operating systems are "multitasking," meaning electronic devices need to run multiple threads simultaneously, but a CPU core can only execute one thread at any given time, the operating system can perform rapid context switching on all running threads in each scheduling cycle. This allocates corresponding CPU time slices to all running foreground and background threads, allowing them to run sequentially according to the allocated order. This creates the illusion for the user that "multiple threads are running simultaneously." Specifically, the switching process first saves the relevant context information of the currently running thread, and then restores the context information of the next thread. The context information mainly includes: saving and restoring relevant register information, and switching the kernel stack and page tables.

[0074] However, the high load and high frequency of the CPU due to frequent processing of background threads, and the frequent context switching between foreground and background threads, will increase CPU overhead and unnecessary power consumption. For example, it will cause the CPU's MIPS (Million Instructions executed per Second) to increase, cause the thread's code and data to be out of the CPU cache, and cause cache invalidation, which will affect the CPU's processing of business threads, and further reduce the battery life of electronic devices and the smoothness of the system.

[0075] The thread scheduling method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0076] The thread scheduling method provided in this application can be applied to scenarios where electronic devices run threads. The following examples illustrate the thread scheduling method provided in this application.

[0077] For example, suppose an electronic device has three foreground threads and two background threads waiting to be run, such as foreground thread A, foreground thread B, and foreground thread C in the foreground thread queue, and background thread 1 and background thread 2 in the background thread queue. When the electronic device is running foreground threads A, B, and C in the foreground thread queue, if the waiting time of background thread 1 in the background thread queue equals a time threshold, the electronic device can run background thread 1. If the waiting time of background thread 2 also reaches the time threshold, and the foreground threads have not finished running, the electronic device can also run background thread 2 while the foreground threads are running. Finally, after all foreground threads in the foreground thread queue have finished running, the electronic device can run background threads 1 and 2 in the background thread queue until both background threads 1 and 2 have finished running.

[0078] It should be noted that the above scenarios are merely illustrative examples of some possible applications of the embodiments of this application. In actual implementation, the embodiments of this application can also be applied to any possible scenarios related to thread operation, such as high load, low power, and user interaction. The embodiments of this application are not limited here.

[0079] Based on the above-mentioned scenario applied in the embodiments of this application, the thread scheduling method provided in this application, when running foreground threads in the foreground thread queue, runs background threads if a first condition is met; the foreground thread queue includes at least one foreground thread; wherein, the first condition includes one of the following: the waiting time of the background thread is greater than or equal to a first threshold; or all foreground threads in the foreground thread queue have finished running. In this solution, when the waiting time of the background thread is greater than or equal to a preset threshold, the electronic device can run the background thread, or, after all foreground threads in the foreground thread queue have finished running, the electronic device can run the background thread in the background thread queue. That is, the electronic device can dynamically control the scheduling timing of the background thread, thereby reducing or avoiding the preemption of CPU resources by the background thread on the foreground thread, ensuring that the foreground thread can obtain CPU resources more effectively, and reducing the risk of lag in the foreground application running on the electronic device. At the same time, since the background thread only has the opportunity to run when the condition is met, the high-frequency invalid running of the background thread can be reduced, and the number of switching between foreground and background threads can be reduced, thereby reducing the operating overhead caused by frequent context switching of the CPU and improving system smoothness.

[0080] The execution subject of the thread scheduling method provided in this application embodiment is a thread scheduling device, which can be an electronic device, or a functional module or entity in an electronic device. This application embodiment does not limit this. The following will use an electronic device as an example to illustrate the thread scheduling method provided in this application embodiment.

[0081] This application provides a thread scheduling method. Figure 3 A flowchart of a thread scheduling method provided in an embodiment of this application is shown. Figure 3 As shown, the thread scheduling method provided in this application embodiment may include the following step 201.

[0082] Step 201: If the first condition is met while the foreground thread in the foreground thread queue is running, the electronic device runs a background thread.

[0083] In this embodiment of the application, the foreground thread queue may include at least one foreground thread.

[0084] In some embodiments of this application, the foreground thread queue can be a CFS rq, that is, the foreground threads in the foreground thread queue can be the foreground threads included in the CFS rq.

[0085] In some embodiments of this application, the aforementioned background thread may be a background thread determined from the background thread queue based on the aforementioned first condition.

[0086] In some embodiments of this application, the aforementioned background thread queue can be a newly created run queue. For example, a run queue named Defer rq can be created.

[0087] In some embodiments of this application, the electronic device may create the aforementioned Defer rq during system runtime to manage background-related threads through the Defer rq.

[0088] In some embodiments of this application, when Defer rq includes multiple background threads, a Completely Fair Scheduling Algorithm similar to CFS can be used to achieve fair scheduling of these multiple background threads through a red-black tree algorithm.

[0089] In some embodiments of this application, the priority of the aforementioned Defer rq can be between that of the CFS rq and the Idle rq. That is, the priorities of the rqs included in the system, from high to low, can be as follows: Figure 4 The order shown.

[0090] It is understandable that after the CPU finishes running the threads in the CFS rq, that is, when the CPU is idle, or when the CPU is preparing to run the threads in the Idle rq in the related technology, in this embodiment of the application, the CPU can run the threads in the Defer rq in priority order.

[0091] In some embodiments of this application, the electronic device can run threads on the CPU core.

[0092] In this embodiment of the application, the first condition may include one of the following: the waiting time of the background thread is greater than or equal to the first threshold; and each foreground thread in the foreground thread queue has finished running.

[0093] In some embodiments of this application, the aforementioned waiting time can be the length of time between the background thread and the last time its CPU time slice expires.

[0094] Understandably, when a background thread obtains a CPU time slice in a certain historical scheduling cycle, the background thread can run based on that CPU time slice. Then, when the background thread's running reaches the time specified by the CPU time slice it obtained, i.e., when the CPU time slice is exhausted, the electronic device can start timing based on the end time of use to determine the waiting time corresponding to the background thread.

[0095] In some embodiments of this application, the aforementioned waiting time may be a system-defined or set duration.

[0096] In some embodiments of this application, the aforementioned first threshold can be determined based on information such as system scheduling policy, thread priority, resource contention intensity, and task characteristics. For example, the duration corresponding to the first threshold can be 100ms.

[0097] It should be noted that the first threshold mentioned above can be determined according to actual needs, and this application embodiment does not limit it here.

[0098] It is understandable that if the foreground threads in the system have too many or too heavy tasks, causing them to occupy CPU time slices for a long time, this will result in background threads not getting CPU time slices for a long time. Therefore, in order to prevent this behavior from causing background threads to starve, electronic devices can increase the comparison between the waiting time of background threads and a first threshold to determine whether the background threads have not received CPU time slices for a long time.

[0099] In some embodiments of this application, if the waiting time of a background thread in the background thread queue is less than a first threshold, then that background thread needs to continue waiting in the background thread queue.

[0100] For example, suppose the background thread queue includes two background threads, such as background thread 1 and background thread 2. During the operation of the foreground thread on the electronic device, if at some point the waiting time of background thread 1 is 100ms (i.e., the waiting time of background thread 1 is equal to a first threshold), then the electronic device can run background thread 1 in the CPU core. At this time, if the waiting time of background thread 2 is 90ms (i.e., the waiting time of background thread 2 is less than the first threshold), then background thread 2 still needs to continue waiting in the background thread queue.

[0101] In some embodiments of the application, the electronic device can detect all background threads in the background thread queue at fixed time intervals based on a detection period to obtain the waiting time corresponding to each background thread. For example, the detection period can be 4ms.

[0102] It should be noted that the duration of the above-mentioned detection cycle can be determined according to actual needs, and this application embodiment does not limit it here.

[0103] It should be noted that, when the first condition is that the waiting time of the background thread is greater than or equal to the first threshold, the specific method for the electronic device to run the background thread can be found in the following description of steps 201a1 to 201a3 and related steps, which will not be repeated here in the embodiments of this application.

[0104] In some embodiments of this application, after all foreground threads in the CFS rq have finished running, the electronic device can run the background threads contained in the Defer rq according to the priority of the run queue; that is, the current pending threads of the electronic device only contain background threads. Therefore, after all foreground threads in the foreground thread queue have finished running, the electronic device can run background threads.

[0105] It should be noted that, when the first condition is that all foreground threads in the foreground thread queue have finished running, the specific method for the electronic device to run background threads can be found in the descriptions of steps 201b1 and 201b2 below, which will not be repeated here in the embodiments of this application.

[0106] In some embodiments of this application, the electronic device can run the background thread by the power corresponding to the background thread.

[0107] It should be noted that the method for determining the power of the background thread mentioned above can be found in steps A1 to A3 below, and will not be repeated here in the embodiments of this application.

[0108] In the thread scheduling method provided in this application embodiment, the electronic device can run the background thread when the waiting time of the background thread is greater than or equal to a preset threshold. Alternatively, the electronic device can run the background thread in the background thread queue after all the foreground threads in the foreground thread queue have finished running. That is, the electronic device can dynamically control the scheduling timing of background threads, thereby reducing or avoiding the preemption of CPU resources by foreground threads, ensuring that foreground threads can obtain CPU resources more effectively, and reducing the risk of stuttering in foreground applications running on the electronic device. Simultaneously, since background threads only have the opportunity to run under certain conditions, high-frequency invalid execution of background threads can be reduced, and the number of switches between foreground and background threads can be reduced, thereby reducing the CPU overhead caused by frequent context switching and improving system smoothness.

[0109] In some embodiments of this application, the thread scheduling method provided in this application may further include the following steps 301 to 303.

[0110] Step 301: The electronic device runs the first foreground thread at the current node according to the first time slice.

[0111] In this embodiment of the application, the first foreground thread can be one of at least one foreground thread.

[0112] In some embodiments of this application, the first time slice can be the maximum duration for which the first foreground thread can continuously execute on the CPU core.

[0113] It is understandable that, when an electronic device determines that it is running a first foreground thread, the electronic device can allocate a first time slice for that first foreground thread to run the first foreground thread based on that first time slice.

[0114] Step 302: After the running time of the first foreground process reaches the duration corresponding to the first time slice, the electronic device determines the second foreground thread to run from the at least one foreground thread based on the virtual runtime of each foreground thread, and allocates a second time slice to the second foreground thread.

[0115] In some embodiments of this application, the second foreground thread can be the foreground thread with the smallest virtual runtime among at least one foreground thread.

[0116] In some embodiments of this application, the second foreground thread may be the same as or different from the first foreground thread.

[0117] Understandably, after the runtime of the first foreground process reaches the duration corresponding to the first time slice, i.e., after the first time slice is exhausted, the electronic device needs to determine the next foreground thread to run from at least one foreground thread waiting to run. Thus, the electronic device can obtain the virtual runtime of each foreground thread in the at least one foreground thread, and determine the thread with the smallest virtual runtime as the second foreground thread, i.e., determine the second foreground thread based on the CFS scheduling algorithm.

[0118] It should be noted that the specific calculation method for the above-mentioned virtual runtime can be found in the relevant technology, and will not be repeated here in the embodiments of this application.

[0119] In some embodiments of this application, the second time slice can be the maximum duration for which the second foreground thread can continuously execute on the CPU core.

[0120] It should be noted that the time slice length for a specific thread can be dynamically determined by the electronic device based on system load and task priority.

[0121] It should be noted that the determination method for the first time slice or the second time slice mentioned above can be found in the determination methods in related technologies, and will not be described in detail in the embodiments of this application.

[0122] Step 303: The electronic device runs the second foreground thread in the next node according to the second time slice.

[0123] In some embodiments of this application, the electronic device may run the second foreground thread within a second time slice, based on the CPU frequency corresponding to the second foreground thread.

[0124] In this embodiment of the application, after the currently running foreground thread finishes running, the electronic device can determine the next running foreground thread based on the virtual runtime. That is, the virtual runtime can be used to achieve fairness and efficiency in the scheduling process of at least one foreground thread, thereby optimizing resource utilization and improving system stability.

[0125] In some embodiments of this application, when the first condition is that the waiting time of the background thread is greater than or equal to a first threshold, combined with Figure 3 ,like Figure 5 As shown, step 201 above can be implemented through steps 201a1 to 201a3 below.

[0126] Step 201a1: If the waiting time of the background thread is greater than or equal to the first threshold, the electronic device determines the target thread for the next node to run from at least one foreground thread and background thread based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of the background thread, and allocates a time slice to the target thread.

[0127] Understandably, if the waiting time of a background thread is greater than or equal to the first threshold, the background thread is at risk of starving. Therefore, electronic devices can combine the background thread with at least one foreground thread while running, so that the background thread has a chance to be run in a short period of time, thereby avoiding the situation where the background thread is starved.

[0128] It should be noted that the specific implementation method of the electronic device determining the target thread to run the next node based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of background threads whose waiting time is greater than or equal to a first threshold, and allocating a time slice to the target thread, can be found in the methods in related technologies, and will not be described in detail here in the embodiments of this application.

[0129] Step 201a2: If the target thread is a background thread, the electronic device runs the background thread in the next node according to the allocated time slice.

[0130] In some embodiments of this application, "the target thread is a background thread" can be understood as: the virtual runtime of the background thread is at least one foreground thread plus the background thread with the smallest virtual runtime. That is, the virtual runtime of the background thread whose waiting time is greater than or equal to the first threshold is less than the virtual runtime of each foreground thread among at least one foreground thread.

[0131] In some embodiments of this application, the electronic device can run the background thread using the power corresponding to the background thread.

[0132] It should be noted that the method for determining the power of the background thread mentioned above can be found in steps A1 to A3 below, and will not be repeated here in the embodiments of this application.

[0133] Step 201a3: After the running time of the target thread reaches the duration corresponding to the allocated time slice, the electronic device continues to determine the foreground thread to run the next node from the at least one foreground thread based on the virtual runtime of each foreground thread in the at least one foreground thread.

[0134] Understandably, if an electronic device avoids starving a background thread by allocating a time slice to it for operation, and the background thread's waiting time is greater than or equal to a first threshold, the electronic device can continue to ignore the background thread's operation requirements. This is to avoid the background thread preempting the foreground thread's resources during continuous operation based on both the foreground thread and the background thread.

[0135] In some embodiments of this application, when the running time of the target thread reaches the duration corresponding to the allocated time slice, that is, after the time slice allocated to the background thread is exhausted, the background thread can start timing as its corresponding waiting time, and continue to wait in the background thread queue until the waiting time is greater than or equal to the first threshold.

[0136] In this embodiment, when the waiting time of a background thread is greater than or equal to a threshold, the electronic device can run the background thread. This means the electronic device can dynamically control the scheduling timing of background threads, thereby reducing or avoiding preemption of CPU resources by foreground threads. This ensures that foreground threads can better acquire CPU resources, reducing the risk of stuttering in foreground applications. Furthermore, since background threads are only allowed to run under certain conditions, high-frequency, ineffective execution of background threads is reduced, as is the number of switches between foreground and background threads. This lowers the CPU overhead caused by context switching and improves system smoothness.

[0137] In some embodiments of this application, when the first condition is that the waiting time of the background thread is greater than or equal to a first threshold, the thread scheduling method provided in this application may further include the following steps 401 and 402.

[0138] Step 401: If the target thread to be run in the next node is a foreground thread, the electronic device will run the target thread in the next node according to the allocated time slice.

[0139] Step 402: After the target thread's running time reaches the duration corresponding to the allocated time slice, the electronic device continues to determine the thread to run the next node from at least one foreground thread and background thread, based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of the background thread.

[0140] It should be noted that the method for determining the thread running on the next node can be found in related technologies using thread scheduling algorithms based on the CFS algorithm, and will not be elaborated upon here in the embodiments of this application.

[0141] It is understandable that the virtual runtime of the aforementioned background thread is not the thread with the smallest virtual runtime among at least one foreground thread and the background thread whose waiting time is greater than or equal to the first threshold. That is, the background thread still needs to wait for at least one judgment so that the electronic device will run the background thread when its virtual runtime is the smallest.

[0142] In this embodiment of the application, the electronic device can determine the next thread to run based on the virtual runtime. That is, the virtual runtime can be used to achieve fairness and efficiency in the scheduling process of at least one foreground thread and background threads with a waiting time greater than or equal to a first threshold, thereby optimizing resource utilization and improving system stability.

[0143] In some embodiments of this application, when the first condition is that each foreground thread in the foreground thread queue has finished running, combined with Figure 3 ,like Figure 6 As shown, step 201 can be implemented through steps 201b1 and 201b2.

[0144] Step 201b1: If each foreground thread in the foreground thread queue finishes running, the electronic device determines the next background thread to run from at least one background thread based on the virtual runtime of each background thread in at least one background thread, and allocates a third time slice to the background thread.

[0145] In some embodiments of this application, since Defer rq manages background threads based on a scheduling algorithm similar to CFS, the electronic device can select the background thread with the shortest virtual runtime from at least one background thread and identify it as the second background thread.

[0146] It should be noted that the calculation method for the virtual runtime and the method for determining the third time slice can be found in the calculation methods in related technologies, and will not be repeated here in the embodiments of this application.

[0147] Step 201b2: The electronic device runs a background thread in the third time slice at the next node.

[0148] In some embodiments of this application, after the second background thread finishes running, the electronic device can again determine the next background thread to run from the at least one background thread based on the virtual runtime of each background thread, and allocate a time slice to that background thread.

[0149] In this embodiment of the application, the electronic device can determine the next background thread to run based on the virtual runtime. That is, the virtual runtime can be used to achieve fairness and efficiency in the scheduling process of at least one background thread, thereby optimizing resource utilization and improving system stability.

[0150] In some embodiments of this application, the thread scheduling method provided in this application may further include the following steps 501 and 502, or may further include the following steps 501 and 503.

[0151] Step 501: In the case of creating or waking up a first thread, the electronic device determines the thread type based on the thread's thread attribute information.

[0152] In this application embodiment, the above-mentioned thread types may include, but are not limited to, background threads and foreground threads.

[0153] In this embodiment of the application, the thread attribute information of the above-mentioned thread may include, but is not limited to, at least one of the following: user interactivity information, real-time requirement information, resource requirement information, priority information, scheduling strategy information, and lifecycle information.

[0154] Step 502: If the electronic device determines that the first thread is a background thread, then store the first thread in the background thread queue.

[0155] Step 503: If the electronic device determines that the first thread is a foreground thread, then store the first thread in the foreground thread queue.

[0156] In some embodiments of this application, when the above thread attribute information includes user interactivity information, if the thread can directly interact with the user, then the thread can be a foreground thread; if the thread cannot directly interact with the user, then the thread can be a background thread.

[0157] In some embodiments of this application, when the above thread attribute information includes real-time requirement information, if the thread is sensitive to latency and requires low-latency response, the thread can be a foreground thread; if the thread runs with a delay, the thread can be a background thread.

[0158] In some embodiments of this application, when the above thread attribute information includes resource requirement information, if a thread has a high CPU quota and dynamic memory requirement, then the thread can be a foreground thread; if a thread has a low CPU requirement and stable memory usage, then the thread can be a background thread.

[0159] In some embodiments of this application, when the above thread attribute information includes priority information, if the thread has a high priority or a low nice value, then the thread can be a foreground thread; if the thread has a low priority or a high nice value, then the thread can be a background thread.

[0160] In some embodiments of this application, when the thread attribute information includes scheduling policy information, if the thread's scheduling policy is a real-time scheduling class, such as SCHED_FIFO or SCHED_RR, then the thread can be a foreground thread; if the thread's scheduling policy is a normal scheduling class, such as SCHED_NORMAL, then the thread can be a background thread.

[0161] In some embodiments of this application, when the above thread attribute information includes lifecycle information, if the thread is bound to the user session and terminates when the user exits, then the thread can be a foreground thread; if the thread is a long-running thread such as a system service, that is, independent of the user session, then the thread can be a background thread.

[0162] In this embodiment, the electronic device can store different types of threads into different running queues, thereby isolating resources and enabling the electronic device to manage threads more accurately, thus improving the accuracy of thread management and execution.

[0163] In some embodiments of this application, when the first thread is a thread with a higher scheduling priority, the electronic device can adaptively store the first thread in a higher priority run queue, such as... Figure 4 The Deadline rq or RT rq are shown.

[0164] In some embodiments of this application, when a thread is created or woken up in the system, since each thread can be assigned to a specific Cgroup, the electronic device can determine whether the thread is a background thread based on the Cgroup it belongs to. For example, the electronic device can identify threads in the Background Group as background threads and threads in the Foreground Group as foreground threads.

[0165] In some embodiments of this application, during the thread creation process, the system can set certain specific threads as background threads to add them to the aforementioned Defer rq.

[0166] In some embodiments of this application, after a thread is created or woken up, the electronic device can detect whether the current screen is on, and then further determine whether the thread meets the conditions for joining Defer rq.

[0167] It should be noted that, since users have high requirements for the smoothness and power consumption of the device when the screen is on, and the running threads are numerous and complex when the screen is on, and the needs of different types of business need to be taken into account, this application focuses on the timing of the device screen being on, but it is also applicable to the timing of the screen being off and other times.

[0168] In some embodiments of this application, the thread scheduling method provided in this application may further include the following step 601.

[0169] Step 601: During the background thread operation, if the second thread in the high-priority thread queue meets the running conditions, the electronic device stops running the background thread and starts running the second thread.

[0170] Understandably, since the scheduling priority of the second thread is higher than that of the running background thread, in order to avoid the running background thread preempting the resources of the second thread, the system can stop the background thread and run the second thread so that the second thread can get CPU time in time, meet the business needs of the second thread, and improve the smoothness of the system.

[0171] In some embodiments of this application, the thread scheduling method provided in this application may further include the following steps A1 to A3.

[0172] Step A1: Before running the background thread, the electronic device calculates the CPU load corresponding to the background thread based on CPU computing power, CPU frequency, and the window size of the time window.

[0173] In some embodiments of this application, the electronic device can be based on CPU computing power and CPU frequency, using the above formula (2), i.e. Calculate the WALTCPU runtime of the background thread to be run, and further, based on the WALTCPU runtime and the window size of the aforementioned duration window, use the above formula (3), i.e. Calculate the CPU load Load_avg corresponding to the background thread.

[0174] Step A2: The electronic device determines the first load corresponding to the background thread based on the CPU load and the preset load range.

[0175] In this embodiment of the application, the first load may be within a preset load range.

[0176] In some embodiments of this application, the aforementioned preset load range is a numerical setting for Uclamp.

[0177] For example, assuming Uclamp_max = 80% and Uclamp_min = 20%, then, taking a load of 1024 as the baseline for Uclamp 100%, the load corresponding to Uclamp_max of 80% is 1, i.e., 1024 × 80% = 819, and the load corresponding to Uclamp_min of 20% is 1024 × 20% = 204. In this case, the preset load range can be [204, 819].

[0178] In some embodiments of this application, when the CPU load is within a preset load range—that is, when the CPU load is less than the maximum value of the preset load range and greater than the minimum value of the preset load range—the electronic device can determine the CPU load as the first load. That is, as follows... Figure 7A The load shown.

[0179] In some embodiments of this application, when the CPU load is greater than or equal to the maximum value of a preset load range, the electronic device can determine the maximum value of the preset load range as the first load. That is, as follows... Figure 7B The load shown.

[0180] In some embodiments of this application, when the CPU load is less than or equal to the minimum value of a preset load range, the electronic device can determine the minimum value of the preset load range as the first load. That is, as follows... Figure 7A The load shown.

[0181] For example, when the CPU load is 300, i.e. within [204, 819], the first load can be 300; when the CPU load is 900, i.e. greater than 819, the first load can be 819; when the CPU load is 150, i.e. less than 204, the first load can be 204.

[0182] Step A3: The electronic device runs a background thread based on the frequency corresponding to the first load.

[0183] In some embodiments of this application, after the electronic device determines the first load, the electronic device can determine the CPU frequency used to run the background thread based on the correspondence between the load and CPU frequency shown in Table 1 above.

[0184] In this embodiment of the application, the electronic device can limit the load of the thread by setting a preset load range, that is, the maximum load of the thread will not exceed the maximum load value of the preset load range. Thus, the background thread can run at a suitable frequency, thereby avoiding power loss caused by running the background thread too frequently, reducing overall energy consumption, and extending the battery life or operating efficiency of the mobile device or server.

[0185] This application provides a thread scheduling method. Figure 8 A flowchart of a thread scheduling method provided in an embodiment of this application is shown. The following will exemplify the thread scheduling method provided in this application, using a foreground thread queue of CFS rq and a background thread queue of Defer rq as an example. Figure 8 As shown, the thread scheduling method provided in this application embodiment may include the following steps 701 to 713.

[0186] Step 701: The electronic device creates or wakes up a thread;

[0187] Step 702: The electronic device determines whether the screen is on.

[0188] Step 703: The electronic device determines the thread type of the thread based on the thread attribute information of the thread.

[0189] Step 704: If the thread is a background thread, the electronic device stores the thread in Deferrq;

[0190] Step 705: If a thread is a foreground thread, the electronic device stores the thread in the corresponding run queue, such as CFS rq.

[0191] Step 706: The electronic device runs the foreground thread in the CFS rq;

[0192] Step 707: The electronic device detects whether the waiting time of the background thread in Defer rq is greater than or equal to the first threshold.

[0193] Step 708: If the waiting time of background thread 1 is greater than or equal to the first threshold, the electronic device obtains the virtual runtime of the foreground thread and background thread 1 in the CFS rq.

[0194] Step 709: The electronic device determines whether the virtual runtime of background thread 1 is minimum;

[0195] Step 710: The electronic device allocates a time slice to background thread 1 for execution;

[0196] Step 711: The electronic device checks whether a thread in a high-priority queue meets the running conditions.

[0197] Step 712: The electronic device allocates time slices to the threads in the high-priority queue for execution;

[0198] It should be noted that the above-mentioned high-priority queue can be understood as any queue with a higher priority than Defer rq, such as Deadline rq, RT rq, or CFS rq.

[0199] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there are no contradictions, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0200] It should be noted that the thread scheduling method provided in this application can be executed by a thread scheduling device. This application uses the example of a thread scheduling device executing the thread scheduling method to illustrate the thread scheduling device provided in this application.

[0201] Figure 9 A schematic diagram of a possible structure of the thread scheduling device involved in an embodiment of this application is shown. For example... Figure 9 As shown, the thread scheduling device 80 may include: a running module 81;

[0202] Among them, the running module 81 is used to run a background thread if a first condition is met when running a foreground thread in the foreground thread queue; the foreground thread queue includes at least one foreground thread.

[0203] The first condition includes one of the following:

[0204] The waiting time of the background thread is greater than or equal to the first threshold;

[0205] Each foreground thread in the foreground thread queue has finished running.

[0206] In one possible implementation, the thread scheduling device provided in this application embodiment may further include: a determining module; the aforementioned running module 81 is further configured to run a first foreground thread at the current node according to a first time slice; wherein, the first foreground thread is one of at least one foreground thread; the determining module is configured to, after the running time of the first foreground process reaches the duration corresponding to the first time slice, determine a second foreground thread to be run at the next node from the at least one foreground thread based on the virtual runtime of each foreground thread, and allocate a second time slice to the second foreground thread; the aforementioned running module 81 is configured to run the second foreground thread determined by the determining module at the next node according to the second time slice.

[0207] In one possible implementation, the thread scheduling device provided in this application embodiment may further include: a determining module; specifically, the determining module is configured to, if the waiting time of the background thread is greater than or equal to a first threshold, determine the target thread to be run in the next node from at least one foreground thread and background thread based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of the background thread, and allocate a time slice to the target thread; the aforementioned running module 81 is configured to, when the target thread is a background thread, run the background thread in the next node according to the allocated time slice; the determining module is further configured to, after the running time of the target thread reaches the duration corresponding to the allocated time slice, continue to determine the foreground thread to be run in the next node from at least one foreground thread based on the virtual runtime of each foreground thread in at least one foreground thread.

[0208] In one possible implementation, the above-mentioned running module 81 is further configured to run the target thread in the next node according to the allocated time slice if the target thread to be run in the next node is a foreground thread; the above-mentioned determining module is further configured to, after the running time of the target thread reaches the duration corresponding to the allocated time slice, continue to determine the thread to be run in the next node from at least one foreground thread and background thread based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of the background thread.

[0209] In one possible implementation, the thread scheduling device provided in this application embodiment may further include: a determining module and a storage module; the determining module is used to determine the thread type of a thread based on the thread attribute information of the thread when a first thread is created or woken up, the thread type including background threads and foreground threads; the storage module is used to store the first thread in a background thread queue if the determining module determines that the first thread is a background thread; or, if the determining module determines that the first thread is a foreground thread, store the first thread in a foreground thread queue.

[0210] In one possible implementation, the thread attribute information of the aforementioned thread includes at least one of the following: user interactivity information, real-time requirement information, resource requirement information, priority information, scheduling strategy information, and lifecycle information.

[0211] In one possible implementation, the thread scheduling device provided in this application embodiment may further include: a determining module; the determining module is used to determine the next background thread to run from at least one background thread based on the virtual runtime of each background thread in at least one background thread if each foreground thread in the foreground thread queue has finished running, and to allocate a third time slice to the background thread; the aforementioned running module 81 is specifically used to run the background thread determined by the determining module in the next node according to the third time slice.

[0212] In one possible implementation, the aforementioned running module 81 is further configured to, during the running of a background thread, if the second thread in the high-priority thread queue meets the running conditions, stop running the background thread and run the second thread.

[0213] In one possible implementation, the thread scheduling device provided in this application embodiment may further include: a calculation module and a determination module; the calculation module is used to calculate the CPU load corresponding to the background thread by means of CPU computing power, CPU frequency and window size of time window before running the background thread; the determination module is used to determine the first load corresponding to the background thread based on the CPU load and a preset load range, wherein the first load is within the preset load range; the aforementioned running module 81 is used to run the background thread based on the frequency corresponding to the first load.

[0214] In the thread scheduling device provided in this application embodiment, when the waiting time of a background thread is greater than or equal to a preset threshold, the thread scheduling device can run the background thread. Alternatively, after all foreground threads in the foreground thread queue have finished running, the thread scheduling device can run the background threads in the background thread queue. That is, the thread scheduling device can dynamically control the scheduling timing of background threads, thereby reducing or avoiding the preemption of CPU resources by foreground threads, ensuring that foreground threads can obtain CPU resources more effectively, and reducing the risk of stuttering in the foreground application running under the thread scheduling device. Simultaneously, since background threads only have the opportunity to run under certain conditions, high-frequency invalid execution of background threads can be reduced, and the number of switches between foreground and background threads can be reduced, thereby reducing the CPU overhead caused by frequent context switching and improving system smoothness.

[0215] The thread scheduling device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0216] The thread scheduling device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0217] The thread scheduling device provided in this application embodiment can implement the various processes implemented in the above method embodiments, and will not be described again here to avoid repetition.

[0218] Optionally, such as Figure 10 As shown, this application embodiment also provides an electronic device 90, including a processor 91 and a memory 92. The memory 92 stores a program or instructions that can run on the processor 91. When the program or instructions are executed by the processor 91, they implement the various steps of the above-described thread scheduling method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0219] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0220] Figure 11 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0221] The electronic device 100 includes, but is not limited to, components such as: radio frequency unit 101, network module 102, audio output unit 103, input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, and processor 110.

[0222] Those skilled in the art will understand that the electronic device 100 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 110 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 11 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0223] The processor 110 is configured to run a background thread when a foreground thread in the foreground thread queue is running, if a first condition is met; the foreground thread queue includes at least one foreground thread; wherein the first condition includes one of the following: the waiting time of the background thread is greater than or equal to a first threshold; or each foreground thread in the foreground thread queue has finished running.

[0224] Optionally, the processor 110 is further configured to run a first foreground thread in the current node according to a first time slice; wherein the first foreground thread is one of at least one foreground thread; and after the running time of the first foreground process reaches the duration corresponding to the first time slice, determine a second foreground thread to run in the next node from the at least one foreground thread based on the virtual runtime of each foreground thread in the at least one foreground thread, allocate a second time slice to the second foreground thread; and run the second foreground thread in the next node according to the second time slice.

[0225] Optionally, the processor 110 is specifically configured to, if the waiting time of the background thread is greater than or equal to a first threshold, determine the target thread to be run in the next node from the at least one foreground thread and the background thread based on the virtual runtime of each foreground thread in the at least one foreground thread and the virtual runtime of the background thread, and allocate a time slice to the target thread; and if the target thread is a background thread, run the background thread in the next node according to the allocated time slice; and after the running time of the target thread reaches the duration corresponding to the allocated time slice, continue to determine the foreground thread to be run in the next node from the at least one foreground thread based on the virtual runtime of each foreground thread in the at least one foreground thread.

[0226] Optionally, the processor 110 is further configured to, if the target thread to be run in the next node is a foreground thread, run the target thread in the next node according to the allocated time slice; and after the running time of the target thread reaches the duration corresponding to the allocated time slice, determine the thread to be run in the next node from at least one foreground thread and background thread based on the virtual runtime of each foreground thread in at least one foreground thread and the virtual runtime of the background thread.

[0227] Optionally, the processor 110 is further configured to, in the case of creating or waking up a first thread, determine the thread type of the thread based on the thread attribute information of the thread, wherein the thread type includes background thread and foreground thread; if the first thread is determined to be a background thread, then the first thread is stored in the background thread queue; or, if the first thread is determined to be a foreground thread, then the first thread is stored in the foreground thread queue.

[0228] Optionally, the thread attribute information of the above-mentioned thread includes at least one of the following: user interactivity information, real-time requirement information, resource requirement information, priority information, scheduling strategy information, and lifecycle information.

[0229] Optionally, if each foreground thread in the foreground thread queue finishes running, the processor 110 determines the background thread to run next from the at least one background thread based on the virtual runtime of each background thread in the at least one background thread, allocates a third time slice to the background thread, and runs the background thread in the third time slice at the next node.

[0230] Optionally, the processor 110 is also configured to, during the execution of a background thread, if the second thread in the high-priority thread queue meets the running conditions, stop running the background thread and run the second thread.

[0231] Optionally, the processor 110 is further configured to calculate the CPU load corresponding to the background thread by means of CPU computing power, CPU frequency and window size of time window before running the background thread; and determine the first load corresponding to the background thread based on the CPU load and a preset load range, wherein the first load is within the preset load range; and run the background thread based on the frequency corresponding to the first load.

[0232] In the electronic device provided in this application embodiment, the electronic device can run the background thread when the waiting time of the background thread is greater than or equal to a preset threshold. Alternatively, the electronic device can run the background thread in the background thread queue after all the foreground threads in the foreground thread queue have finished running. That is, the electronic device can dynamically control the scheduling timing of the background thread, thereby reducing or avoiding the preemption of CPU resources by the background thread on the foreground thread, ensuring that the foreground thread can obtain CPU resources more effectively, and reducing the risk of stuttering in the foreground application running on the electronic device. At the same time, since the background thread only has the opportunity to run when the conditions are met, the high-frequency invalid running of the background thread can be reduced, and the number of switching between foreground and background threads can be reduced, thereby reducing the operating overhead caused by the CPU performing frequent context switching and improving system smoothness.

[0233] The electronic device provided in this application embodiment can implement the various processes implemented in the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0234] The beneficial effects of the various implementation methods in this embodiment can be found in the beneficial effects of the corresponding implementation methods in the above method embodiments. To avoid repetition, they will not be repeated here.

[0235] It should be understood that, in this embodiment, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 107 includes at least one of a touch panel 1071 and other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0236] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 109 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0237] Processor 110 may include one or more processing units; optionally, processor 110 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 110.

[0238] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0239] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0240] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0241] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0242] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0243] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0244] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0245] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A thread scheduling method, characterized in that, The method includes: When a foreground thread in the foreground thread queue is running, a background thread is run if the first condition is met; the foreground thread queue includes at least one foreground thread. The first condition includes one of the following: The waiting time of the background thread is greater than or equal to the first threshold; Each foreground thread in the foreground thread queue has finished running.

2. The method according to claim 1, characterized in that, The method further includes: The first foreground thread runs at the current node according to the first time slice; wherein the first foreground thread is one of the at least one foreground thread; After the first foreground process has run for the duration corresponding to the first time slice, based on the virtual runtime of each foreground thread in the at least one foreground thread, the second foreground thread to run next is determined from the at least one foreground thread, and a second time slice is allocated to the second foreground thread. The second foreground thread runs in the second time slice at the next node.

3. The method according to claim 1 or 2, characterized in that, If the first condition is that the waiting time of the background thread is greater than or equal to a first threshold, then running the background thread if the first condition is met includes: If the waiting time of the background thread is greater than or equal to the first threshold, then based on the virtual runtime of each of the at least one foreground thread and the virtual runtime of the background thread, the target thread for the next node to run is determined from the at least one foreground thread and the background thread, and a time slice is allocated to the target thread. If the target thread is the background thread, the background thread runs in the next node according to the allocated time slice; After the target thread's running time reaches the duration corresponding to the allocated time slice, based on the virtual runtime of each of the at least one foreground thread, the next foreground thread to run is determined from the at least one foreground thread.

4. The method according to claim 3, characterized in that, The method further includes: If the target thread to be run in the next node is a foreground thread, then the target thread will run in the next node according to the allocated time slice; After the target thread's running time reaches the duration corresponding to the allocated time slice, based on the virtual runtime of each foreground thread in the at least one foreground thread and the virtual runtime of the background thread, the thread to run next node is determined from the at least one foreground thread and the background thread.

5. The method according to claim 1, characterized in that, The method further includes: When creating or waking up a first thread, the thread type of the thread is determined based on the thread attribute information of the thread, and the thread type includes background threads and foreground threads; If it is determined that the first thread is a background thread, then the first thread is stored in the background thread queue; If the first thread is determined to be a foreground thread, then the first thread is stored in the foreground thread queue.

6. The method according to claim 5, characterized in that, The thread attribute information of the thread includes at least one of the following: user interactivity information, real-time requirement information, resource requirement information, priority information, scheduling strategy information, and lifecycle information.

7. The method according to claim 1, characterized in that, If the first condition is that all foreground threads in the foreground thread queue have finished running, then running the background thread if the first condition is met includes: If each foreground thread in the foreground thread queue finishes running, then based on the virtual runtime of each background thread in the at least one background thread, the next background thread to run is determined from the at least one background thread, and a third time slice is allocated to the background thread. The background thread runs in the third time slice at the next node.

8. The method according to claim 1, characterized in that, The method further includes: If the second thread in the high-priority thread queue meets the running conditions during the execution of a background thread, then the background thread is stopped and the second thread is executed.

9. The method according to claim 1, characterized in that, The method further includes: Before running the background thread, the CPU load corresponding to the background thread is calculated based on the CPU computing power, CPU frequency, and window size of the time window. Based on the CPU load and the preset load range, the first load corresponding to the background thread is determined, and the first load is within the preset load range; The background thread is run based on the frequency corresponding to the first load.

10. A thread scheduling device, characterized in that, The thread scheduling device includes: a running module; The operating model is used to run background threads when a first condition is met while running foreground threads in the foreground thread queue; the foreground thread queue includes at least one foreground thread. The first condition includes one of the following: The waiting time of the background thread is greater than or equal to the first threshold; Each foreground thread in the foreground thread queue has finished running.

11. The apparatus according to claim 10, characterized in that, The device further includes: a determining module; The running module is further configured to run a first foreground thread at the current node according to a first time slice; wherein the first foreground thread is one of the at least one foreground thread; The determining module is used to determine the second foreground thread to run next node from the at least one foreground thread based on the virtual runtime of each foreground thread in the first foreground thread after the running time of the first foreground process reaches the duration corresponding to the first time slice, and to allocate a second time slice to the second foreground thread. The running module is used to run the second foreground thread determined by the determining module in the second time slice at the next node.

12. The apparatus according to claim 10 or 11, characterized in that, The device further includes: a determining module; The determining module is configured to, if the waiting time of the background thread is greater than or equal to the first threshold, determine the target thread for the next node to run from the at least one foreground thread and the background thread based on the virtual runtime of each foreground thread in the at least one foreground thread and the virtual runtime of the background thread, and allocate a time slice to the target thread. The running module is specifically used to run the background thread in the next node according to the allocated time slice when the target thread determined by the determining module is the background thread. The determining module is further configured to, after the running time of the target thread reaches the duration corresponding to the allocated time slice, determine the next foreground thread to run from the at least one foreground thread based on the virtual runtime of each foreground thread in the at least one foreground thread.

13. The apparatus according to claim 10, characterized in that, The device further includes: a determining module; The determining module is used to determine the next running background thread from the at least one background thread based on the virtual runtime of each background thread in the at least one background thread if each foreground thread in the foreground thread queue has finished running, and to allocate a third time slice to the background thread. The running module is specifically used to run the background thread determined by the determining module according to the third time slice at the next node.

14. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the thread scheduling method as described in any one of claims 1 to 9.

15. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the thread scheduling method as described in any one of claims 1 to 9.

Images