Thread scheduling method, electronic device, and computer-readable storage medium

Abstract

The application provides a thread scheduling method, an electronic device and a computer readable storage medium, and relates to the technical field of terminals. An operating system of the electronic device can record and query a thread blocking relationship through a bitmap. The operating system can also find, according to the thread blocking relationship, in a waiting queue of a first thread lock, a thread that is blocked by other threads and needs to hold the first thread lock preferentially among all threads in the waiting queue of the first thread lock. The operating system adds a first mark to the first thread that needs to hold the first thread lock preferentially, and after the first thread lock is released by a second thread, the first thread with the first mark can hold the first thread lock preferentially. For a part of the first threads that need to hold the first thread lock preferentially among all threads in the electronic device, the operating system can find the part of the first threads that need to hold the first thread lock preferentially, so that the first threads hold the first thread lock preferentially, and the influence of long-time blocking on the overall process of an application is avoided as soon as possible, and a thread scheduling scheme is optimized.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a thread scheduling method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Multiple threads run within an electronic device, and these threads may be blocked due to reasons such as waiting for thread locks. When any thread is waiting to acquire a thread lock, it first enters the waiting queue for the corresponding thread lock. When the thread currently holding the lock releases the lock, it searches the waiting queue for one or more threads waiting to hold the lock, and wakes up one or more threads in the waiting queue in the order they waited to acquire the lock.

[0003] Existing thread scheduling schemes can only schedule threads sequentially according to the order in which they are requested, based on the waiting queue of thread locks. This cannot effectively solve the technical problem of long-term thread blocking, thus affecting the overall application process. Summary of the Invention

[0004] This application provides a thread scheduling method, an electronic device, and a computer-readable storage medium to solve the technical problem of long-term thread blocking.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, this application provides a thread scheduling method for electronic devices, such as mobile phones and tablets. The electronic device includes an operating system that runs on its processor. The operating system can create and schedule threads. The thread scheduling method provided in this application prioritizes certain threads based on their blocking relationships, minimizing prolonged blocking caused by waiting for thread locks and optimizing the overall application process. The main steps of the thread scheduling method provided in this embodiment can be executed by the operating system, and some steps can also be executed by threads created by the operating system.

[0007] Among the multiple threads created by the operating system, there is a first thread waiting to acquire the first-thread lock. This first thread is in the waiting queue for the first-thread lock. The second thread currently holds the first-thread lock, and there may be other threads in the waiting queue. Some of these other threads in the waiting queue may be ahead of the first thread, thus blocking it. The first thread may need to be scheduled quickly due to its higher priority or other reasons. If the first thread is blocked for a long time, it will have a significant impact on the overall application process; therefore, the first thread is the thread that needs to acquire the lock first.

[0008] The operating system can search the waiting queue of the first thread lock for the thread that is blocked by other threads and needs to acquire the lock first. For example, the operating system can use factors such as thread priority and predefined priority lock acquisition rules to find the first thread that is blocked by other threads and needs to acquire the lock first. Then, the operating system can add a first flag to the first thread, indicating that the first thread is the thread that needs to acquire the lock first.

[0009] In this way, when the second thread releases the first thread lock, the first thread with the first flag can acquire the first thread lock first. Here, "first thread acquires first thread lock first" refers to the time it takes for other threads that precede the first thread to acquire the lock.

[0010] Operating systems can employ various methods to determine inter-thread blocking relationships. For example, they can use the waiting queues or lock request records of each thread to query these relationships. Alternatively, they can create a separate dataset to record inter-thread blocking relationships at different times. By querying the elements in this dataset, the corresponding inter-thread blocking relationship can be found. This dataset can be a table or a bitmap, among other data structures.

[0011] The thread scheduling method provided in this application targets the first thread among all threads in an electronic device that needs to acquire the lock first. The operating system can find this first thread that needs to acquire the lock first and add a first mark. This allows the first thread with the first mark to acquire the lock first, so as to avoid the impact of long-term blocking on the overall process of the application as soon as possible, thus optimizing the thread scheduling scheme.

[0012] In one possible implementation of the first aspect, the operating system searches for the first thread that is blocked by other threads and needs to acquire the lock first. The operating system may find the first thread, in which case it can add a first flag to the first thread. Of course, the operating system may not find the first thread. If no first thread needs to acquire the lock first is found, the operating system can search for the thread with the longest waiting time and acquire the lock first. In this way, the operating system can both ensure that the first thread needs to acquire the lock first, and also allow threads with longer waiting times to acquire the lock first.

[0013] The operating system searches for the third thread with the longest waiting time among all threads in the waiting queue of the first thread lock. If the waiting queue of the first thread lock is a first-in, first-out queue, the operating system can select the thread that is first in the queue as the third thread. Alternatively, the operating system can find the third thread based on the time when each thread requested the first thread lock, which is also the thread with the longest waiting time.

[0014] The operating system searches for the third thread in the waiting queue of the first thread lock to have the longest waiting time. A second flag is added to this third thread, indicating that it is the thread with the longest waiting time. Thus, when the second thread currently holding the first thread lock releases the lock, the third thread with the second flag can acquire the first thread lock.

[0015] The thread scheduling method provided in this embodiment allows the operating system to prioritize scheduling the thread that has been waiting for the lock the longest if there is no thread that needs to hold the lock first. This avoids some threads waiting for the lock to be acquired for too long, thereby optimizing the overall application process.

[0016] In one possible implementation of the first aspect, the addition of a first marker by the operating system to indicate the first thread that needs to acquire the lock first is further specified. Specifically, the operating system sets a priority lock-acquiring pointer, which points to the thread that needs to acquire the lock first, thereby marking the thread that needs to acquire the lock first.

[0017] The operating system places the priority lock-holding pointer in the first-thread lock's waiting queue, pointing it to the first thread. When the current lock-holding thread (i.e., the second thread) releases the first-thread lock, the second thread wakes up the first thread whose priority lock-holding pointer is pointing to, allowing the first thread to acquire the first-thread lock.

[0018] In one possible implementation of the first aspect, the provided thread scheduling method further includes an automatic thread wake-up scheme. For a thread requiring a lock to run, two conditions must be met: holding the corresponding thread lock and being scheduled by the operating system. Some low-priority threads, even if they acquire the corresponding thread lock, cannot obtain computing resources due to their low priority and therefore cannot be scheduled by the operating system; they will remain in a dormant state and unable to run, even if they hold the lock. Some high-priority threads can acquire computing resources but need to wait to acquire the thread lock and cannot run. The thread scheduling scheme provided in this embodiment matches an automatic wake-up function to high-priority threads waiting to acquire the thread lock. These threads can wake up threads holding locks but in a dormant state, allowing threads holding locks but in a dormant state to be scheduled with priority.

[0019] Specifically, if the fourth thread created by the operating system has a high priority or other matching attribute parameters, the operating system can configure an automatic wake-up function for the fourth thread. In this way, when the fourth thread requests the second thread lock and enters the second thread lock's waiting queue, the operating system's matched automatic wake-up function can automatically wake the fourth thread at multiple automatic wake-up times after it enters the second thread lock's waiting queue.

[0020] In one specific implementation, the operating system can configure the automatic wake-up function for threads using a timer. For example, if the fourth thread is the main thread, the operating system can configure a timer for the fourth thread to have a corresponding automatic wake-up function. The timer sends a timed wake-up message to the fourth thread at each automatic wake-up time, and the timed wake-up message is used to wake up the fourth thread at each automatic wake-up time.

[0021] At each automatic wake-up time, the fourth thread wakes itself up and wakes up the fifth thread that is currently holding the lock but not running. The fifth thread refers to the thread that currently holds the second thread lock and is directly or indirectly blocked waiting for the fourth thread to acquire the second thread lock. After the fourth thread finds the fifth thread currently holding the second thread lock, if the fifth thread is not scheduled, the fourth thread adds a third flag to the fifth thread so that the operating system prioritizes scheduling the fifth thread with the third flag. In this way, the fourth thread wakes up the fifth thread currently holding the second thread lock, allowing the fifth thread to be scheduled first, and the fourth thread waiting to acquire the second thread lock can also acquire the second thread lock relatively sooner.

[0022] In one possible implementation of the first aspect, the scheme of the fourth thread searching for the fifth thread at different wake-up times is further defined. The operating system assigns a timer corresponding to the automatic wake-up function of the fourth thread, corresponding to multiple automatic wake-up times. There is a certain time interval between adjacent automatic wake-up times, which can be a fixed duration. For ease of description, this is defined as the first automatic wake-up time and the second automatic wake-up time. In the actual scheme, from the time the fourth thread enters the waiting queue for the second thread lock to the time the fourth thread acquires the second thread lock, the timer can determine an automatic wake-up time at fixed intervals, and the number of automatic wake-up times can be multiple.

[0023] At the first automatic wake-up time, the fourth thread searches for the thread holding the lock that the second thread locked at the first automatic wake-up time, and selects it as the fifth thread for that time. At the second automatic wake-up time, the fourth thread searches for the thread holding the lock that the second thread locked at the second automatic wake-up time, and selects it as the fifth thread for that time. The fifth thread for the first automatic wake-up time and the fifth thread for the second automatic wake-up time can be the same thread or different threads.

[0024] In other words, the fourth thread will wake itself up at each automatic wake-up time and look for the thread currently holding the second thread lock. If the thread currently holding the second thread lock has not been scheduled, the fourth thread will wake up the thread currently holding the second thread lock that has not been scheduled so that it can be scheduled first.

[0025] If the lock-holding thread at the first automatic wake-up time is still in a state of holding the lock but not being scheduled at the second automatic wake-up time, then the lock-holding thread woken up by the fourth thread at the second automatic wake-up time will still be the same thread woken up at the first automatic wake-up time.

[0026] If the lock-holding thread at the first automatic wake-up time has been scheduled or has released the second thread lock before the second automatic wake-up time, then the lock-holding thread woken up by the fourth thread at the second automatic wake-up time will be different from the lock-holding thread woken up at the first automatic wake-up time.

[0027] In one possible implementation of the first aspect, the implementation scheme for the fourth thread to search for the fifth thread is limited. Specifically, the fourth thread first searches for the sixth thread that is directly blocking the fourth thread. The sixth thread may have acquired the second thread lock, or it may be blocked by other threads and has not yet acquired the second thread lock.

[0028] In one scenario, if the sixth thread, which directly blocks the fourth thread, acquires the lock of the second thread, the fourth thread can treat the sixth thread as the fifth thread, and then determine whether the fifth thread needs to be woken up based on the scheduling state of the fifth thread.

[0029] In another scenario, if the sixth thread, which directly blocks the fourth thread, fails to acquire the second thread lock, the fourth thread needs to continue searching for the seventh thread, which directly blocks the sixth thread, and then process the request based on the seventh thread's lock-holding state. If the seventh thread acquires the second thread lock, it becomes the fifth thread, and the fourth thread determines whether to wake up either the fifth or seventh thread based on its scheduling state. If the seventh thread also fails to acquire the second thread lock, the fourth thread needs to further search for other threads that directly block the seventh thread, recursively searching according to the thread blocking relationships until it finds a thread that indirectly blocks the fourth thread and holds the second thread lock, which becomes the fifth thread.

[0030] This implementation identifies threads that are directly or indirectly blocking the fourth thread and hold the lock for the second thread. It can effectively wake up the currently holding thread and prioritize its scheduling, thereby speeding up the overall application process.

[0031] In one possible implementation of the first aspect, a scheme is defined as recording inter-thread blocking relationships using a bitmap. The electronic device stores a bitmap; wherein the bitmap records all inter-thread blocking relationships within the electronic device. The bitmap comprises a matrix, where the element value in the m-th row and n-th column indicates the blocking relationship between thread m and thread n, where m and n are thread numbers. A first value indicates no blocking between threads, and a second value indicates blocking between threads. In one possible implementation of the first aspect, the first value is 0, and the second value is 1.

[0032] For example, if the value of the element in the first row and second column is 0, it indicates that thread 1 is not blocked by thread 2; if the value of the element in the first row and second column is 1, it indicates that thread 1 is blocked by thread 2. As another example, if the value of the element in the second row and first column is 0, it indicates that thread 2 is not blocked by thread 1; if the value of the element in the second row and first column is 1, it indicates that thread 2 is blocked by thread 1.

[0033] Specifically, the thread scheduling method provided by the electronic device, which uses a bitmap to query the blocking relationship between threads, can include the following: The operating system queries the element value in the first target row corresponding to the first thread in the bitmap to obtain the blocking relationship between threads within the electronic device. The first target row has multiple column element values, with different column element values ​​indicating the blocking status of the first thread by the corresponding number. It should be noted that the first thread here is not limited to thread 1, the first target row is not limited to the first row of the bitmap, the subsequent second thread, etc., are not limited to thread 2, and the second target column is not limited to the second column of the bitmap; the following related descriptions are similar.

[0034] In one possible implementation of the first aspect, the specific acquisition scheme of the bitmap recording inter-thread blocking relationships is further defined. The operating system of the electronic device creates the bitmap, and the thread whose inter-thread blocking relationship changes actively modifies the element values ​​in the bitmap to update the inter-thread blocking relationship in real time. Other threads can search the element values ​​of each row and column in the bitmap to query the real-time inter-thread blocking relationship, including their own inter-thread blocking relationship and the inter-thread blocking relationships associated with other threads.

[0035] For ease of description, the following explanation will focus on the perspective of the eighth thread, illustrating how a thread modifies the element values ​​in the bitmap when its associated inter-thread blocking relationships change, particularly the implementation schemes for the three main nodes of acquiring, distributing, and requesting thread locks, which involve changes in inter-thread blocking relationships. The eighth thread can be any thread created by the operating system.

[0036] Specifically, the bitmap creation and modification scheme in the thread scheduling method provided in this embodiment may include: the operating system creating a bitmap and setting the element values ​​in the bitmap to a first value. The eighth thread modifies the element values ​​in the bitmap according to the changes in the blocking relationship between threads.

[0037] The operating system can create a bitmap when the first thread is created. The number of rows and columns in the bitmap can be equal to the maximum number of threads the operating system can create. When the operating system creates the bitmap, there is no inter-thread blocking. The operating system can first set all element values ​​in the bitmap to the first value, which indicates that there is no blocking between threads.

[0038] When the eighth thread acquires a thread lock, it introduces inter-thread blocking relationships. When the eighth thread releases the thread lock, it reduces these relationships. Using a bitmap to record these relationships is a simple, quick, and easy-to-find method that doesn't require adding extra members to the task structure. It's suitable for various types of thread locks and eliminates the need for periodic checks of blocking status. The operating system can effectively identify and quickly schedule blocked threads, reducing application lag.

[0039] In one possible implementation of the first aspect, a scheme for modifying the element values ​​in the bitmap involved in requesting a thread lock is defined. The steps by which the eighth thread modifies the element values ​​in the bitmap based on changes in the inter-thread blocking relationship can specifically include: when the eighth thread requests the third thread lock at the first moment, it searches for the ninth thread that is blocking the eighth thread; the eighth thread modifies the element values ​​of the second target columns corresponding to each ninth thread in the first target row corresponding to the eighth thread in the bitmap to a second value.

[0040] The eighth thread requests the third thread lock at the first moment. The third thread lock is currently held by another thread, and there are other threads that have previously requested to acquire the third thread lock in the waiting queue of the third thread lock. The thread holding the third thread lock and all threads in the waiting queue of the third thread lock block the eighth thread from acquiring the third thread lock, and are referred to as the ninth thread.

[0041] When thread eight requests the lock of thread three, it searches for all ninth threads that are blocking thread eight. To record the relationship between newly added ninth threads and thread eight, thread eight modifies the element values ​​of the second target columns corresponding to each ninth thread in the first target row of the bitmap to the second value. In this way, thread eight or other threads can query the element values ​​of all columns in the first target row to determine which threads are blocking thread eight and thus the thread blocking relationships associated with thread eight.

[0042] In one possible implementation of the first aspect, a scheme for modifying the element values ​​in the bitmap involved in acquiring the thread lock is defined. After the eighth thread modifies the element values ​​of the second target columns corresponding to each ninth thread in the first target row of the bitmap to a second value, when the eighth thread acquires the third thread lock at a second time, the ninth threads that previously held the third thread lock and those that first requested the third thread lock no longer block the eighth thread. The eighth thread modifies the element values ​​of each second target column in the first target row of the bitmap to a first value to indicate that the ninth threads that previously blocked the eighth thread no longer block the eighth thread.

[0043] Furthermore, when the eighth thread acquires the third thread lock, it blocks other threads currently waiting to acquire the third thread lock. The eighth thread can also record newly added inter-thread blocking relationships. Specifically, when the eighth thread acquires the third thread lock, it first searches for all threads in the waiting queue for the third thread lock at the second moment, denoted as the tenth thread. The eighth thread modifies the element values ​​of the third target rows corresponding to each tenth thread in the first target column of the bitmap to the second value. In this way, by querying the element values ​​of each row in the first target column, the eighth thread can obtain which threads it has blocked and determine the inter-thread blocking relationships associated with the eighth thread.

[0044] In one possible implementation of the first aspect, a scheme for modifying the element values ​​in the bitmap involved in releasing the thread lock is defined. After the eighth thread modifies the element values ​​of the third target rows corresponding to each tenth thread in the first target column of the bitmap to a second value, when the eighth thread releases the first thread lock at a third moment, the eighth thread no longer blocks the tenth thread currently waiting to acquire the third thread lock. The eighth thread modifies the element values ​​of each third target row in the first target column of the bitmap to a first value to indicate that the eighth thread that previously blocked the tenth thread no longer blocks the tenth thread.

[0045] In a second aspect, this application provides an electronic device, which includes a memory and a processor. The operating system of the electronic device runs on the processor, and the memory is coupled to the processor. The memory stores computer-executable instructions. The operating system schedules the processor to execute the computer-executable instructions stored in the memory, so that the electronic device executes the thread scheduling method as described in any of the first aspects.

[0046] In one possible implementation of the second aspect, the operating system is used to:

[0047] In the waiting queue of the first thread lock, find the first thread; where the first thread refers to the thread in the waiting queue of the first thread lock that is blocked by other threads and needs to acquire the lock first, and the current thread holding the lock of the first thread lock is the second thread.

[0048] The operating system adds a first flag to the first thread;

[0049] The second thread releases the lock of the first thread, and the first thread with the first tag acquires the lock.

[0050] In one possible implementation of the second aspect, the operating system is further configured to:

[0051] If the first thread is not found, the operating system searches for the third thread in the waiting queue of the first thread lock; where the third thread refers to the thread with the longest waiting time among all the threads in the waiting queue of the first thread lock.

[0052] The operating system adds a second flag to the third thread;

[0053] The second thread releases the lock of the first thread, and the third thread, marked with the second tag, acquires the lock of the first thread.

[0054] In one possible implementation of the second aspect, the steps of the operating system adding a first flag to the first thread, the second thread releasing the first thread lock, and the first thread with the first flag acquiring the first thread lock include:

[0055] The operating system places the priority lock-holding pointer in the first thread's wait queue and points it to the first thread; whereby the priority lock-holding pointer pointing to the first thread indicates that the first thread has added the first flag.

[0056] When the second thread releases the lock of the first thread, the second thread wakes up the first thread that holds the lock pointer first, so that the first thread can acquire the lock of the first thread.

[0057] In one possible implementation of the second aspect, the thread scheduling method further includes:

[0058] The fourth thread requests the lock of the second thread and enters the waiting queue of the second thread lock; the fourth thread has the function of automatically waking up at multiple automatic wake-up times;

[0059] At each automatic wake-up time, the fourth thread searches for the fifth thread; where the fifth thread is the current lock-holding thread of the second thread lock, and the fifth thread directly or indirectly blocks the fourth thread;

[0060] If the fifth thread is not scheduled, the fourth thread adds the third flag to the fifth thread;

[0061] Electronic devices prioritize scheduling the fifth thread, which has been added with a third flag.

[0062] In one possible implementation of the second aspect, at each automatic wake-up time, the fourth thread, according to the step of finding the fifth thread, includes:

[0063] At the first automatic wake-up time, the fourth thread finds the thread holding the lock that the second thread locked at the first automatic wake-up time, and becomes the fifth thread corresponding to the first automatic wake-up time.

[0064] At the second automatic wake-up time, the fourth thread finds the thread holding the lock that the second thread locked at the second automatic wake-up time, and becomes the fifth thread corresponding to the second automatic wake-up time.

[0065] Among them, the fifth thread corresponding to the first automatic wake-up time and the fifth thread corresponding to the second automatic wake-up time are either the same thread or different threads.

[0066] In one possible implementation of the second aspect, the step of the fourth thread searching for the fifth thread includes:

[0067] The fourth thread searches for the sixth thread, which is directly blocking the fourth thread.

[0068] If the sixth thread, which directly blocks the fourth thread, acquires the lock of the second thread, then the sixth thread will be treated as the fifth thread.

[0069] If the sixth thread, which directly blocks the fourth thread, fails to acquire the lock of the second thread, then search for the seventh thread, which directly blocks the sixth thread.

[0070] If the seventh thread acquires the lock of the second thread, then the seventh thread will be treated as the fifth thread.

[0071] In one possible implementation of the second aspect, before the step of the fourth thread requesting the second thread lock and entering the waiting queue of the second thread lock, the method further includes:

[0072] If the fourth thread is the main thread, the operating system will configure a timer with the corresponding automatic wake-up function for the fourth thread.

[0073] The timer sends a timed wake-up message to the fourth thread at each automatic wake-up time; the timed wake-up message is used to wake up the fourth thread at each automatic wake-up time.

[0074] In one possible implementation of the second aspect, the electronic device stores a bitmap; wherein the bitmap records the blocking relationships between all threads within the electronic device, the bitmap includes a row and column matrix, the element value of the m-th row and n-th column of the row and column matrix indicates the blocking relationship between thread m and thread n, the element value is a first value indicating no blocking between threads, the element value is a second value indicating blocking between threads, and m and n are both thread numbers.

[0075] Thread scheduling methods also include:

[0076] The operating system queries the element value in the first target row corresponding to the first thread in the bitmap to obtain the blocking relationship between threads within the electronic device.

[0077] In one possible implementation of the second aspect, the thread scheduling method further includes:

[0078] The operating system creates a bitmap and sets the value of each element in the bitmap to the first value.

[0079] The eighth thread modifies the element values ​​in the bitmap based on the changes in the blocking relationship between threads; the eighth thread is the thread whose blocking relationship between threads has changed.

[0080] In one possible implementation of the second aspect, the step of the eighth thread modifying the element values ​​in the bitmap based on changes in inter-thread blocking relationships includes:

[0081] When the eighth thread requests the third thread lock at the first moment, it searches for the ninth thread; where the ninth thread is all the threads that blocked the eighth thread at the first moment, including the thread holding the third thread lock at the first moment and all the threads in the waiting queue of the third thread lock;

[0082] The eighth thread modifies the element values ​​of the second target columns corresponding to each ninth thread in the first target row of the bitmap to the second value.

[0083] In one possible implementation of the second aspect, after the step of the eighth thread modifying the element values ​​of the second target columns corresponding to each ninth thread in the first target row corresponding to the eighth thread in the bitmap to the second value, the thread scheduling method further includes:

[0084] When the eighth thread acquires the lock of the third thread at the second moment, the eighth thread modifies the element values ​​of each second target column in the first target row of the bitmap to the first value;

[0085] The eighth thread searches for the tenth thread; where the tenth thread is all the threads in the waiting queue of the third thread lock at the second moment.

[0086] The eighth thread modifies the element value of the third target row corresponding to each tenth thread in the first target column of the bitmap to the second value.

[0087] In one possible implementation of the second aspect, after the eighth thread modifies the element values ​​of the third target rows corresponding to each tenth thread in the first target column of the bitmap to the second value, the thread scheduling method further includes:

[0088] When the eighth thread releases the lock of the first thread at the third moment, the eighth thread modifies the element values ​​of each third target row in the first target column of the bitmap to the first value.

[0089] In one possible implementation of the second aspect, the first value is 0 and the second value is 1.

[0090] Thirdly, an electronic device is provided, which has the function of implementing the thread scheduling method of the first aspect described above. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0091] Fourthly, a computer-readable storage medium is provided that stores instructions which, when executed on a computer, enable the computer to perform any of the thread scheduling methods described in the first aspect above.

[0092] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements a thread scheduling method as described in any of the first aspects.

[0093] The technical effects of any of the design methods in aspects two through five can be found in the technical effects of different design methods in aspect one, and will not be repeated here. Attached Figure Description

[0094] Figure 1 A schematic diagram of the waiting queue for a thread lock;

[0095] Figure 2 A flowchart illustrating the thread scheduling method provided in an embodiment of this application;

[0096] Figure 3 A schematic diagram illustrating the process of using a bitmap to record the blocking relationship between threads in the thread scheduling method provided in the embodiments of this application;

[0097] Figure 4 A schematic diagram illustrating the process of prioritizing the acquisition of thread locks in the thread scheduling method provided in this application embodiment;

[0098] Figure 5 A schematic diagram of the thread lock and priority lock holding pointer involved in the thread scheduling method provided in the embodiments of this application;

[0099] Figure 6 A flowchart illustrating the priority scheduling of threads involved in the thread scheduling method provided in this application embodiment;

[0100] Figure 7 A schematic diagram of the thread lock and priority scheduling pointer involved in the thread scheduling method provided in the embodiments of this application;

[0101] Figure 8 A flowchart illustrating the fast and slow paths involved in the thread scheduling method provided in this application embodiment;

[0102] Figure 9 A schematic diagram showing the effect comparison before and after thread scheduling in the thread scheduling method provided in the embodiments of this application;

[0103] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0104] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0105] To facilitate understanding, some technical common sense involved in the embodiments of this application will be introduced first.

[0106] Electronic devices consist of an operating system (OS) and a central processing unit (CPU). The operating system primarily manages various computing tasks within the electronic device, handling task scheduling and resource allocation. The CPU primarily executes these computing tasks. Multiple applications run on the operating system, each with different functionalities.

[0107] A process is the carrier of an application's execution and an independent unit for resource allocation and task scheduling by the operating system. A process is one execution of a program, while a thread is a single sequential flow of control within program execution; it is the smallest unit of program execution flow and the basic unit of CPU scheduling and dispatching. A process can have one or more threads. A thread typically consists of a thread ID (Identity Document), a program counter (PC), registers, and a stack. Electronic devices use thread IDs to identify and distinguish threads. Thread IDs can start from 0 and are numbered sequentially according to the order of thread creation; thread IDs within electronic devices typically range from 0 to 32767.

[0108] When an application starts, the operating system creates a process and begins running a thread, called the main thread. The main thread can create multiple child threads. Within a process, the main thread has a relatively high priority, while child threads typically have a lower priority than the main thread.

[0109] A process can include memory space allocated by the operating system and multiple threads created within it. All threads within a process can access the resources in the memory space corresponding to that process. Each thread within a process can perform read and modify operations on the resources in the memory space. Modification operations can include adding, modifying, and deleting. To avoid errors that may occur when multiple threads access and occupy the same resource, electronic devices can also introduce thread locks. A thread lock is a thread control tool used to control the access permissions and order of multiple threads to shared resources.

[0110] For example, thread A acquires thread lock 1 before accessing shared resource 1 and releases thread lock 1 after finishing accessing shared resource 1. During the period when thread A holds thread lock 1, the shared resource is usually not accessed by other threads. Similarly, if thread B needs to access shared resource 1, thread B also needs to acquire thread lock 1 first. If thread lock 1 is held by thread A when thread B requests it, then thread B must wait until thread A finishes accessing shared resource 1 and releases thread lock 1 before it can acquire thread lock 1 and access shared resource 1.

[0111] Thread locks mainly include read-write locks (RWsem Locks) and mutexes. Read-write locks are used to control the read and write functions of threads on shared resources. A read-write lock allows multiple threads to read the same resource simultaneously, but only one thread is allowed to write to the same resource at a time.

[0112] A mutex lock is used to restrict a thread's access to a shared resource. When the current thread holds the mutex lock, only the current thread can access the shared resource. Other threads must wait for the current thread to release the mutex lock before they can acquire the lock or the mutex lock and then access the shared resource.

[0113] For example, if the current thread requests a mutex lock and the mutex lock is held by another thread, the current thread will relinquish the CPU. The CPU can then execute the computational tasks of other threads. When the current thread acquires the mutex lock, it can then occupy the CPU to execute its computational tasks.

[0114] During the operation of electronic devices, the types and numbers of thread locks introduced may vary, and the types and numbers of threads requesting each thread lock may also differ. The operating system can create a corresponding waiting queue for each thread lock, which includes threads waiting to acquire the thread lock.

[0115] For example Figure 1 As shown in (a), thread 1 holds thread lock 1, and threads 2, 3, 4, 5, etc. wait to acquire thread lock 1. Threads 2, 3, 4, 5, etc., will be added to the waiting queue of thread lock 1. In other words, thread 1 holds thread lock, and threads 2, 3, 4, 5, etc. are blocked by thread 1 because they are waiting to acquire thread lock 1.

[0116] For example Figure 1 As shown in (b), thread 7 holds thread lock 2. The waiting queue for thread lock 2 includes threads 10, 13, 14, and 15. Threads 10, 13, 14, and 15 are blocked by thread 7 because they are waiting to acquire thread lock 2.

[0117] During the operation of an electronic device, the reasons why threads may be blocked include waiting for external resources, other threads, or triggering conditions. Waiting for a thread lock is a major cause of thread blocking. It should be noted that thread blocking due to waiting for a thread lock can occur not only between multiple threads within the same process, but also between multiple threads in different processes. The thread blocking discussed in this application can refer to blocking between multiple threads within the same process or between multiple threads in different processes, and is not limited thereto.

[0118] Existing thread scheduling schemes in electronic devices involve the following process: When a thread is waiting to acquire a thread lock, it first enters the corresponding thread lock's waiting queue. When the thread currently holding the lock releases it, it searches the waiting queue for one or more threads waiting to acquire the lock and wakes up one or more of these threads in the order they were waiting to acquire the lock. However, existing thread scheduling schemes can only schedule threads sequentially based on the waiting queue and the order in which they are requested, which cannot effectively solve the technical problem of long-term thread blocking and thus affects process performance.

[0119] For example, thread 1, which currently holds the thread lock, has a low priority and is unlikely to acquire computing resources allocated by the operating system. Thread 2, which is waiting to acquire the thread lock, has a higher priority, but enters a prolonged blocked state because it needs to wait for thread 1 to release the thread lock. Generally speaking, the blocking time of higher-priority threads has a greater impact on the process.

[0120] Based on this, this application provides a thread scheduling method applied to an electronic device. The electronic device records the blocking relationships between threads and optimizes the thread scheduling scheme by querying the blocking relationships between threads to speed up the process. The electronic device to which the thread scheduling method provided in this embodiment is applied may include a personal computer (PC), tablet computer, laptop computer, portable computer (such as a mobile phone), wearable electronic device (such as a smartwatch), augmented reality (AR) / virtual reality (VR) device, in-vehicle computer, and other electronic devices with a processor. The following embodiments do not impose any special limitations on the specific form of the electronic device.

[0121] like Figure 2 The diagram shown is a flowchart of a thread scheduling method provided in an embodiment of this application. The thread scheduling method provided in this embodiment is mainly executed by the operating system of the electronic device. Specifically, the thread scheduling method provided in this embodiment mainly includes the following two operations:

[0122] S21: The operating system records the blocking relationships between threads;

[0123] S22: The operating system optimizes the thread scheduling scheme based on the blocking relationship between threads.

[0124] The process of performing the above two operations on electronic devices will be described in detail below.

[0125] In the first part, the electronic device executes S21. The operating system of the electronic device can use various methods to record the blocking relationship between threads.

[0126] Multiple threads may run concurrently within an electronic device. Due to factors such as waiting for thread locks, external resources, and triggering conditions, each thread may be blocked by other threads, and each thread may also block other threads. Furthermore, the blocking relationships between threads may be the same or different at different times.

[0127] For example, at the first moment, based on thread lock 1, thread A blocks thread B, and thread B blocks thread C. At the second moment, based on thread lock 1, thread B blocks thread C. At the third moment, based on thread lock 2, thread C blocks both thread A and thread B.

[0128] The blocking relationships between threads recorded by an electronic device can include: whether each thread is currently blocked by other threads, and whether each thread is blocking other threads. The electronic device can use a dataset in one or more formats, such as tables, mapping tables, or arrays, to record these blocking relationships. When recording these relationships in the dataset, the electronic device can identify each thread by its ID.

[0129] In one implementation, the electronic device can record the blocking relationships between threads through the wait queues of each thread lock.

[0130] Suppose there is a thread lock, denoted as the first thread lock. The first thread lock is currently held by the first thread. There are one or more threads, denoted as the second threads, in the waiting queue of the first thread lock, waiting to acquire it. The first thread blocks all second threads, and all second threads are blocked by the first thread. Electronic devices can obtain the blocking relationships between threads by querying the threads holding the locks and the threads in the waiting queues for each thread lock.

[0131] In another specific implementation, the electronic device may use a bitmap as a dataset to record the blocking relationships between threads.

[0132] A bitmap is a data structure consisting of a matrix of rows and columns, where each element has a value of either 0 or 1. Electronic devices can set the number of rows and columns in the matrix according to the size of the required dataset, and record multiple data points using the element values ​​within the matrix.

[0133] In one example, the electronic device creates a matrix of rows and columns of a bitmap, where the row number and index both correspond to thread IDs, and the element values ​​correspond to the blocking state between threads.

[0134] The number of threads within an electronic device is denoted as A. All threads, sorted by their thread IDs, can be: thread 0, thread 1, thread 2, ..., thread (A-2) and thread (A-1). An A*A matrix can be used to represent the blocking relationships between threads. Each element of the matrix is ​​either 0 or 1, where 0 indicates no blocking and 1 indicates blocking.

[0135] For example, the value of the element in row i and column k represents the state of thread i being blocked by thread k. If the value of the element in row i and column k is 1, it means that thread i is blocked by thread k. If the value of the element in row i and column k is 0, it means that thread i is not blocked by thread k.

[0136] For example, the value in row k and column i represents the state of thread k being blocked by thread i. If the value of the element in row k and column i is 1, it means that thread k is blocked by thread i. If the value of the element in row k and column i is 0, it means that thread k is not blocked by thread i.

[0137] Table 1 shows a bitmap example of how an electronic device records the blocking relationships between threads. For ease of understanding, in this example, it is assumed that the number of threads A is 10, and the electronic device records the blocking relationships between threads using a 10*10 matrix.

[0138] Table 1

[0139] As shown in Table 1, the values ​​in each column of row 0 represent the state of thread 0 being blocked by other threads, while the data in each row of column 0 represents the blocking state of thread 0 against other threads. A value of 0 indicates no blocking, and 1 indicates blocking. It should be noted that for any i < 10, the value of the element in the i-th row and i-th column is 0, meaning the thread will not be blocked by itself.

[0140] For example, in row 1, the elements in columns 0, 2, 3, and 6 have a value of 1, indicating that thread 1 is blocked by threads 0, 2, 3, and 6. In row 1, the elements in columns 1, 4, 5, 7, 8, and 9 have a value of 0, indicating that thread 1 is not blocked by threads 4, 5, 7, 8, and 9.

[0141] For example, in column 4, the elements in rows 3, 6, and 7 with a value of 1 indicate that thread 4 blocked threads 3, 6, and 7. In column 4, the elements in rows 0, 1, 2, 4, 5, 8, and 9 with a value of 0 indicate that thread 4 did not block threads 0, 1, 2, 4, 5, 8, and 9.

[0142] In another specific example, the electronic device can also update the element values ​​in the bitmap in real time to update the recorded inter-thread blocking relationships.

[0143] Table 1 above shows the bitmap corresponding to the inter-thread blocking relationship at the first moment recorded by the electronic device. Table 2 below shows the bitmap corresponding to the inter-thread blocking relationship at the second moment recorded by the electronic device. The second moment is a moment after the first moment.

[0144] Table 2

[0145] As shown in Table 2, compared to Table 1, the value of the element in row 0, column 7 changes from 1 to 0, and the value of the element in row 0, column 8 changes from 1 to 0. All columns in row 1 have their values ​​changed to 0. That is to say, at the second moment, thread 0 is no longer blocked by thread 7, thread 0 is currently blocked by thread 8, and thread 1 is not currently blocked by any other thread.

[0146] The electronic device updates the element values ​​in the bitmap in real time based on changes in the blocking relationships between threads. In this way, the electronic device can directly query the element values ​​in the current bitmap to obtain the real-time blocking relationships between threads.

[0147] In one specific implementation, the entity executing S21 in the electronic device can be the operating system within the electronic device, or it can be any thread within the electronic device.

[0148] The operating system within an electronic device possesses thread management and scheduling capabilities, enabling it to monitor changes in the blocking relationships between threads. The operating system creates a bitmap to record these blocking relationships. It can also monitor changes in these relationships and update the values ​​of the elements representing the blocking relationships in the bitmap accordingly. It's important to note that "operating system" here can refer to the entire operating system of the electronic device or specifically to the scheduler within the operating system responsible for thread scheduling.

[0149] Each thread within an electronic device can also create its own corresponding row and column matrices in the bitmap, or update the element values ​​in the corresponding row and column matrices. Each thread can update the element values ​​of the corresponding row and column in the bitmap based on changes in its blocking relationship.

[0150] In one example, the process of the operating system executing S21 can specifically include:

[0151] S21a: Create a bitmap;

[0152] S21b: Update the bitmap when acquiring a thread lock;

[0153] S21c: When acquiring the thread lock, update the bitmap;

[0154] S21d: Update the bitmap when releasing the thread lock.

[0155] S21a is the step of creating the bitmap that needs to be executed first, and S21b-S21d are the steps of updating the bitmap according to the blocking relationship between threads, which will be explained in detail later.

[0156] When an electronic device is powered on or when the operating system creates its first thread, the operating system executes S21a to create a bitmap. The bitmap created by the operating system can be a matrix of rows and columns, each with one row and one column. Subsequently, each time the operating system creates a new thread, the operating system or the newly created thread adds one row and one column to the initial bitmap to update the size of the bitmap's matrix.

[0157] In another scenario, when an electronic device powers on or when the operating system creates its first thread, the operating system can directly create a bitmap containing a large matrix of rows and columns, ensuring that the matrix can essentially cover the entire number of threads on the electronic device. This way, the operating system doesn't need to resize the bitmap when creating new threads.

[0158] like Figure 3 As shown, the operating system may include the following steps when executing step S21a:

[0159] S211: The operating system creates a bitmap; where the bitmap consists of a row and column matrix, and the number of rows and columns of the row and column matrix are both the maximum number of threads.

[0160] S212: The operating system sets the element value in the bitmap to the first value; where the first value indicates that threads do not block each other.

[0161] The newly created bitmap by the operating system consists of a matrix of rows and columns. The number of rows and columns in this matrix can both be the maximum number of threads the operating system can create, i.e., the maximum number of threads. The maximum number of threads the operating system can create is 32768, or 2^32 threads. 15 Table 3 shows a partial row and column matrix diagram of the bitmap. Table 3 illustrates the bitmap regions corresponding to 10 threads; this is for a simple example only and is not intended to limit the solution.

[0162] For a given current thread 'a', the number A of blocked threads 'a' is equal to the number B of elements with a value of 1 in all 32768 columns of row 'a'. 36768 = 215 Then the number of threads blocking thread a is A=2. B ,2 B ≤2 15 *2, that is, 2 B ≤2 16 Electronic devices can use 8-bit, 16-bit, 32-bit, and 64-bit binary counting modes. Therefore, an electronic device can use a 16-bit or 32-bit integer to record the number A of blocked thread 'a'.

[0163] A bitmap created by the operating system can have two values ​​for each element of its matrix, denoted as the first value and the second value. The first value indicates that threads do not block each other, while the second value indicates that threads block each other. In one example, the first value can be 0, and the second value can be 1.

[0164] When the operating system creates a new bitmap, it first sets all element values ​​in the bitmap to the first value to indicate that there is no inter-thread blocking at the beginning.

[0165] Table 3

[0166] During the operation of an electronic device, if the blocking relationship between threads changes, the bitmap can be updated by the thread whose blocking relationship has changed.

[0167] The primary cause of inter-thread blocking is waiting for thread locks. In other words, whether a thread acquires a thread lock is the main factor causing changes in the inter-thread blocking relationship. The relationship between a thread and a thread lock includes, in sequence: a thread requests a thread lock, a thread acquires a thread lock, and a thread releases a thread lock. When the relationship between a thread and a thread lock changes, the associated inter-thread blocking relationship changes. A thread can update the element values ​​of its associated region in the bitmap based on these changes.

[0168] Corresponding to the three relationships between threads and thread locks mentioned above, the thread scheduling method provided in this embodiment mainly includes the following three scenarios for updating inter-thread blocking relationships:

[0169] In the first scenario, the thread requests a thread lock, adds a blocked relationship, and executes S21b.

[0170] In the second scenario, the thread acquires the thread lock, adds a blocking relationship, and executes S21c.

[0171] In the third scenario, the thread releases the thread lock, reducing blocking and executing S21d.

[0172] For the first scenario above, the thread requests a thread lock, a new blocked relationship is created, and the S21b solution is executed. This mainly includes the following steps:

[0173] S213: The eighth thread requests the third thread lock at the first moment and searches for the ninth thread; where the ninth thread is all the threads that blocked the eighth thread at the first moment, including the thread holding the third thread lock at the first moment and all the threads in the waiting queue of the third thread lock.

[0174] S214: The eighth thread modifies the element value of the second target column corresponding to each ninth thread in the first target row of the bitmap to the second value; the second value indicates inter-thread blocking.

[0175] In the thread scheduling methods of electronic devices, any thread created by the operating system can request a thread lock. For ease of description, the thread currently being described is referred to as the eighth thread, and the thread lock requested by the eighth thread is referred to as the third thread lock. The third thread lock can be any type of thread lock. At some point during the execution of the eighth thread, it needs to request the third thread lock; this moment is recorded as the first moment. It should be noted that the eighth thread is specified here for consistency throughout the text and does not limit the number, creation order, etc., of the eighth thread. It is only used to explain the thread scheduling scheme that can be applied to the eighth thread. The eighth thread can be any thread created by the operating system, and the same applies to the naming of each thread and thread lock thereafter.

[0176] The eighth thread requests the third thread lock at the first moment, which will create new blocking relationships between the eighth thread and other threads within the electronic device. These new blocking relationships can be categorized into two scenarios: first, the eighth thread requests the third thread lock at the first moment but fails; second, the eighth thread requests the third thread lock at the first moment and succeeds.

[0177] In the first scenario, the eighth thread fails to acquire the third thread lock, typically because the third thread lock may already be held by another thread. In this case, there may be one or more other threads waiting to acquire the third thread lock in the waiting queue, and these other threads may have acquired the third thread lock earlier. Both the thread currently holding the third thread lock and the threads in the waiting queue will block the eighth thread. For ease of description, we will refer to the thread currently holding the third thread lock and the threads in the waiting queue as the ninth thread; there may be one or more ninth threads.

[0178] The eighth thread requests the lock of the third thread at the first moment but fails to do so. The ninth thread, which is blocking the eighth thread, is identified, and the blocking relationship between the eighth and ninth threads is updated in the bitmap.

[0179] In the bitmap, the eighth thread corresponds to the first target row and the first target column, and the ninth thread corresponds to the second target row and the second target column. The element values ​​in the first target row represent the state where the eighth thread is blocked by other threads, and the element values ​​in the first target column represent the state where the eighth thread is blocking other threads. Similarly, the element values ​​in the second target row represent the state where the ninth thread is blocked by other threads, and the element values ​​in the second target column represent the state where the ninth thread is blocking other threads. Therefore, the element value in the second target column of the first target row can represent the state where the eighth thread is blocked by the ninth thread.

[0180] It should be noted that the first target row does not refer to the first row in the bitmap, the first target column does not refer to the first column in the bitmap, the second target row does not refer to the second row in the bitmap, and the second target column does not refer to the second column in the bitmap. There may be multiple ninth threads, and there may be multiple corresponding second target rows and second target columns.

[0181] In one example, the eighth thread is thread 0. At the first moment, thread 0 requests the third thread lock, thread lock A. Thread lock A is currently held by thread 1, and the waiting queue for thread lock A also includes threads 2 through 7. The thread holding thread lock A (i.e., thread 1) and the threads that requested it earlier (i.e., threads 2 through 7) block thread 0.

[0182] In other words, at the first moment, thread 0 requests thread lock A, but the request fails. Thread 0 finds that the current thread holding thread lock A is thread 1, and in the waiting queue of thread lock A, it finds threads 2-7 that previously requested thread lock A and are still waiting to acquire it. Thread 0 determines that threads 1-7 are the ninth thread blocking thread 0.

[0183] In the bitmap, the first target row corresponding to thread 0 is row 0, and the second target columns corresponding to threads 1-7 are columns 1-7. Thread 0 modifies the element values ​​of row 0 and columns 1-7 in the bitmap of Table 3 from 0 to 1, resulting in Table 4 as shown below.

[0184] Table 4

[0185] In the second scenario, the eighth thread successfully acquires the third thread lock at the first moment, usually because the third thread lock is not currently held by any other thread, or there are no other threads waiting to acquire the third thread lock in the eighth thread's waiting queue. Therefore, at the first moment, when the eighth thread acquires the third thread lock, there is no ninth thread blocking it. In other words, the blocking relationship of the eighth thread remains unchanged, and the eighth thread does not need to modify the element values ​​in the corresponding area of ​​the bitmap; the bitmap can still be as shown in Table 3.

[0186] For the second scenario above, the solution of acquiring a thread lock, adding a blocking relationship, and executing S21c can mainly include the following steps:

[0187] S215: When the eighth thread acquires the lock of the third thread at the second moment, the eighth thread modifies the element values ​​of each second target column in the first target row of the bitmap to the first value.

[0188] S216: The eighth thread searches for the tenth thread; where the tenth thread is all the threads in the waiting queue of the third thread lock at the second moment;

[0189] S217: The eighth thread modifies the element value of the third target row corresponding to each tenth thread in the first target column of the bitmap to the second value.

[0190] The eighth thread requests the third thread lock at the first moment and enters the waiting queue for the third thread lock. At some point after the first moment, the eighth thread acquires the third thread lock. This moment is recorded as the second moment, which is after the first moment. There are two scenarios for the eighth thread acquiring the third thread lock: first, it acquires the third thread lock in the order it was requested; second, the eighth thread acquires the third thread lock first.

[0191] In the first scenario, all ninth threads acquire and release the third thread lock, and the eighth thread acquires the third thread lock at the second moment. At the second moment, all ninth threads no longer block the eighth thread. The eighth thread can modify the element value of the second target column corresponding to each ninth thread in the first target row of the bitmap to the first value, indicating that the ninth threads will no longer block the eighth thread.

[0192] In the second scenario, the eighth thread might acquire the third thread lock first. Because the eighth thread has a higher priority than some ninth threads, or because the operating system schedules the eighth thread first, it might acquire the third thread lock before some ninth threads. In this case, some ninth threads that have already acquired and released the third thread lock will no longer block the eighth thread, while those ninth threads still waiting to acquire the third thread lock will be blocked by the eighth thread instead of blocking it. Since all ninth threads are no longer blocking the eighth thread, the eighth thread can modify the element value of the second target column corresponding to each ninth thread in the first target row of the first graph to the first value, indicating that the ninth threads will no longer block the eighth thread.

[0193] When the eighth thread acquires the third thread lock at the second moment, it can determine all threads currently waiting to acquire the third thread lock, namely the tenth thread currently blocked by the eighth thread. If the eighth thread acquires the third thread lock in the first scenario described above, then all tenth threads have requested the third thread lock after the first moment. If the eighth thread acquires the third thread lock in the second scenario described above, then some of the tenth threads have requested the third thread lock before the first moment, meaning the tenth threads include some of the previous ninth threads.

[0194] The eighth thread determines all tenth threads that are blocked by querying the waiting queue of the third thread lock, and modifies the element value of the third target row corresponding to each tenth thread in the first target column of the bitmap to the second value.

[0195] In one example, continuing with the bitmap shown in Table 4 above, at the second moment, thread 0 acquires thread lock A.

[0196] In the first scenario, threads 1 through 7 will no longer block thread 0. As shown in Table 5, thread 0 will modify the values ​​of columns 1 through 7 in row 0 of the bitmap to 0. If thread 0 determines that threads 8 and 9 are the tenth threads currently waiting to acquire thread lock A, as shown in Table 5, thread 0 can modify the values ​​of the elements in column 0 of the bitmap, specifically row 8 corresponding to thread 8 and row 9 corresponding to thread 9, to 1.

[0197] Table 5

[0198] In the second scenario, threads 1 through 7 will no longer block thread 0. As shown in Table 6, thread 0 first modifies the values ​​of the elements in columns 1 through 7 of row 0 in the bitmap to 0. Threads 4 through 9 are blocked by thread 0, and thread 0 can also modify the values ​​of the elements in rows 4 through 9 of column 0 to 1. Furthermore, thread 0 determines that threads 8 and 9 are also the tenth threads currently waiting to acquire thread lock A, and thread 0 can modify the values ​​of the elements in row 8 corresponding to thread 8 and row 9 corresponding to thread 9 of column 0 in the bitmap to 1.

[0199] Table 6

[0200] In other cases, it is possible that when the eighth thread acquires the lock of the third thread, there is no tenth thread currently waiting to acquire the lock in the waiting queue of the third thread. The eighth thread does not find the tenth thread and does not need to modify the element values ​​in the bitmap.

[0201] For the third scenario above, the thread releases the thread lock, reduces blocking, and executes the S21d solution, which mainly includes the following steps:

[0202] S218: When the eighth thread releases the lock of the third thread at the third moment, the eighth thread modifies the element values ​​of each third target row in the first target column of the bitmap to the first value.

[0203] The eighth thread acquires the third thread lock at time two and releases it at some point after time two. This time of release is designated as time three, which occurs after time two. Once the eighth thread releases the third thread lock, it no longer blocks any of the tenth threads. The eighth thread can then modify the values ​​of the elements in each of the third target rows in the first target column of the bitmap to the first value, indicating that it will no longer block the tenth threads.

[0204] When the eighth thread releases the third thread lock, one or more threads in the tenth thread group will acquire the third thread lock. For ease of description, the thread currently holding the third thread lock among all tenth threads will be designated as the eleventh thread, and the thread currently waiting to acquire the third thread lock will be designated as the twelfth thread.

[0205] The eleventh thread acquires the lock of the third thread and blocks, waiting for the twelfth thread to acquire the lock. The eleventh thread can modify the value of the element in the fifth target row corresponding to the twelfth thread in the fourth target column of the bitmap to the second value.

[0206] In one example, continuing as shown in Table 6 above, thread 0 releases thread lock A, and thread 4 acquires thread lock A. As shown in Table 7, thread 0 modifies the element values ​​in column 0, rows 4-9 of the bitmap to 0. Furthermore, thread 4 modifies the element values ​​in column 4, rows 5-9 of the bitmap to 1.

[0207] Table 7

[0208] In other cases, it's possible that when the eighth thread releases the lock from the third thread, the waiting queue for the third thread lock doesn't contain the eleventh and twelfth threads currently waiting to acquire it. In this scenario, the eighth thread only needs to modify the element value in the first target column.

[0209] Electronic devices employ a bitmap-based approach to record inter-thread blocking relationships, resulting in clearer and more transparent representations. The bitmap data structure is independent of thread computation tasks and thread locks, eliminating the need for additional nodes in the task structure (task_struct) and lock data structures. Furthermore, bitmap-based recording of inter-thread blocking relationships does not require differentiation of thread locks, making it suitable for blocking relationships arising from multiple thread locks within electronic devices. The electronic device updates the bitmap whenever inter-thread blocking relationships are updated, eliminating the need for periodic queries and checks of these relationships.

[0210] Secondly, the operating system executes S22 to optimize the thread scheduling scheme based on the blocking relationship between threads.

[0211] Electronic devices can execute thread scheduling schemes based on the blocking relationships between threads to accelerate thread execution. There are two main thread scheduling schemes that electronic devices can execute: the first scheme is that the operating system controls the threads currently waiting to acquire thread locks to execute S22a, prioritizing the acquisition of thread locks; the second scheme is that the operating system executes S22b, prioritizing thread scheduling, especially for threads that have already acquired thread locks and are waiting to be scheduled.

[0212] For the first approach, the operating system, based on the blocking relationship between threads, ensures that the first thread waiting to acquire the first thread lock acquires it first.

[0213] Within an electronic device, a first-thread lock is currently held by a second thread. The waiting queue for the first-thread lock contains one or more threads waiting to acquire it. Among all the second threads in the waiting queue, the thread that needs to acquire the first-thread lock first is denoted as the first thread.

[0214] The electronic device determines the first thread that needs to acquire the lock from all threads in the waiting queue of the first thread lock, and allows the first thread to acquire the lock first. For example, the electronic device can determine the thread with the highest priority as the first thread.

[0215] In one example, such as Figure 4 As shown, S22a may mainly include the following steps:

[0216] S221: The operating system searches for the first thread in the waiting queue of the first thread lock; where the first thread refers to the thread in the waiting queue of the first thread lock that is blocked by other threads and needs to acquire the lock first, and the current thread holding the lock of the first thread lock is the second thread.

[0217] S222: The operating system adds the first flag to the first thread.

[0218] S223: The second thread releases the lock of the first thread, and the first thread with the first mark acquires the lock.

[0219] Electronic devices create multiple threads, each performing different computational tasks, with varying degrees of importance, urgency, and priority. For threads with higher importance, urgency, or priority, prolonged waiting times may impact the overall process. When creating threads, or during thread execution, the electronic device can mark threads with higher importance, urgency, or priority as those requiring priority scheduling. Priority-scheduled threads must acquire the lock first to be scheduled. Specifically, the operating system searches the thread lock's waiting queue for the thread that needs priority in acquiring the lock.

[0220] In one example, the electronic device can set a priority lock pointer, which points to the thread that needs to hold the lock first.

[0221] In practice, the operating system places a priority lock-holding pointer in the waiting queue of the first thread lock, pointing it to the first thread. This indicates that the first thread has added a first flag. Thus, when the second thread releases the first thread lock, it can wake up the first thread pointed to by the priority lock-holding pointer, allowing the first thread to acquire the first thread lock.

[0222] Specifically, the electronic device can also create a task_struct pointer blocker on the processor's run queue as a priority lock holder pointer, pointing to the thread in the first thread lock waiting queue that needs to hold the lock first.

[0223] An electronic device can determine whether a thread needs to acquire the lock by checking if the priority lock pointer is null. If the priority lock pointer is null, it means there is no thread that needs to acquire the lock. If the priority lock pointer is not null, it means there is a thread that needs to acquire the lock.

[0224] The electronic device queries the priority lock pointer to determine if there is a thread that needs to acquire the lock first. If the electronic device determines that there is a thread that needs to acquire the lock first, it can designate that thread as the first thread. When the current lock-holding thread (i.e., the second thread) releases the first thread's lock, the first thread can be woken up to acquire the lock first.

[0225] like Figure 5As shown in (a), thread lock 1 is held by thread 1, and the waiting queue of thread lock 1 includes threads 2, 3, 4, and 5. The priority lock-holding pointer points to thread 4, thus determining that thread 4 is the thread that needs to hold the lock first.

[0226] like Figure 5 As shown in (b), thread lock 2 is held by thread 7, and the waiting queue for thread lock 2 includes threads 10, 13, 14, and 15, etc. The priority pointer is null, indicating that there is no pointer that needs to hold the lock first.

[0227] When thread 1 releases thread lock 1, thread 4 acquires thread lock 1. Compared to threads 2 and 3, which are ahead of thread 4 in the waiting queue for thread lock 1, thread 4 acquires thread lock 1 first. This speeds up thread 4's progress, thereby optimizing the overall application process.

[0228] Continue as Figure 4 As shown, S22a may also include a thread scheduling scheme for when no priority lock-holding thread is found, specifically including:

[0229] S224: If the first thread is not found, the operating system searches for the third thread in the waiting queue of the first thread lock; where the third thread refers to the thread with the longest waiting time among all the threads in the waiting queue of the first thread lock.

[0230] S225: The operating system adds a second flag for the third thread;

[0231] S226: The second thread releases the lock of the first thread, and the third thread with the second tag acquires the lock of the first thread.

[0232] The electronic device queries the priority scheduling pointer. If it determines that there is no first thread that needs to be scheduled first, it can find the third thread with the longest waiting time and add a second flag to the third thread. When the third thread releases the lock of the first thread, the third thread acquires the lock of the first thread.

[0233] Continue as Figure 5 As shown in (b), thread 7 acquires thread lock 2. Since there are no threads requiring priority scheduling in the waiting queue of thread 2, we can further determine that thread 10 has the longest waiting time. When thread 7 releases thread lock 2, thread 10, which has the longest waiting time, acquires thread lock 2.

[0234] In practice, determining the first thread and the entity responsible for waking it up can be the second thread that releases the first thread's lock. When releasing the first thread's lock, the second thread checks the first thread's lock waiting queue to determine if the priority lock pointer is null, thus identifying the first thread. The second thread then wakes up the first thread, which then acquires the first thread's lock.

[0235] It should be noted that threads entering the waiting queue of the first thread lock are typically in a sleeping state, and their running state parameters correspond to this sleeping state. The second thread waking up the first thread means that the second thread modifies the first thread's running state parameters to match the parameters for that specific running state. Both acquiring and releasing the thread lock require following a pre-defined path and lasting a certain amount of time to complete.

[0236] When the second thread begins to release the lock of the first thread, it wakes up the first thread, which then begins to pre-hold the lock. After the second thread completely releases the lock, the first target thread acquires the lock.

[0237] In practical implementation, the operating system can also insert a hook point in the pick_next_task_fair function of the CFS scheduler (Completely Fair Scheduler) to select the path of the next task. It checks whether the blocker pointer of the current queue is null. If it is not null, it prioritizes the blocker recorded by the pointer for scheduling.

[0238] The thread scheduling scheme provided in this embodiment can determine the first thread that needs to hold the lock first based on the blocking relationship between threads, so that the first thread can acquire the first thread lock first, thereby speeding up the overall process.

[0239] For the second approach, the electronic device is configured with an automatic wake-up function for the fourth thread. While the fourth thread is waiting to acquire the lock of the second thread, the fifth thread, which is blocking the fourth thread, can be scheduled first, so that the fourth thread can acquire the lock of the second thread as soon as possible.

[0240] In one specific implementation, such as Figure 6 As shown, the electronic device performing S22b may include the following steps:

[0241] S227: The fourth thread requests the second thread lock and enters the waiting queue of the second thread lock; the fourth thread has the function of automatically waking up at multiple automatic wake-up times.

[0242] Among the multiple threads created by an electronic device, some threads have higher priority, such as the main thread. If a high-priority thread remains blocked for an extended period, it will affect the overall application process. Therefore, the electronic device is configured with an automatic wake-up function for some high-priority threads. This automatic wake-up function can be configured using a timer. For ease of description, the thread configured with the self-wake-up function is referred to as the fourth thread.

[0243] In one specific implementation, if the fourth thread is the main thread, and the main thread has a relatively high priority, then blocking the main thread has a significant impact on the overall application process. For the case where the fourth thread is the main thread, the operating system can configure a timer for the fourth thread to implement an automatic wake-up function. The timer sends a timed wake-up message to the fourth thread at each automatic wake-up time, and this message is used to wake up the fourth thread at each automatic wake-up time.

[0244] The fourth thread is configured with a timer, primarily possessing two wake-up functions: self-wake-up and waking up other threads. The self-wake-up function means that after entering a sleep state, the fourth thread can automatically wake up at regular intervals. The waking up other threads function means that each time the fourth thread automatically wakes up, it can also wake up other threads that are in a sleep state.

[0245] For example, if the timer is set to a period of 10 microseconds, then after the fourth thread enters a sleep state, it can wake itself up every 10 microseconds and wake up other threads that are in a sleep state.

[0246] A fourth thread with automatic wake-up capability requests the second thread lock. If the second thread lock is currently held by another thread, the fourth thread will enter the waiting queue of the second thread lock. Threads entering the waiting queue of the second thread lock are usually in a sleeping state and can only be woken up by other threads. The fourth thread, however, entering the waiting queue of the second thread lock is in an Uninterrupted Sleep state and can be automatically woken up by receiving wake-up messages sent periodically by a timer.

[0247] In actual operation, according to the timer's set interval of n microseconds, the timer sends a wake-up message to the fourth thread every n microseconds. The fourth thread wakes itself up based on the wake-up message and then enters a sleep state. The fourth thread will continuously alternate between self-wake-up and sleep states until it acquires the lock of the second thread and ends its sleep state, at which point the timer stops sending wake-up messages to the fourth thread. For ease of description, the moment when the timer wakes up the fourth thread each time is defined as the automatic wake-up moment.

[0248] S228: At each automatic wake-up time, the fourth thread searches for the fifth thread; wherein the fifth thread is the current lock-holding thread of the second thread lock, and the fifth thread directly or indirectly blocks the fourth thread.

[0249] S229: If the fifth thread is not scheduled, the fourth thread adds the third flag to the fifth thread.

[0250] S2210: The operating system prioritizes scheduling the fifth thread that has been added with a third flag.

[0251] At each automatic wake-up time, the second target thread, the fourth thread, wakes itself up and searches the bitmap for the thread currently holding the second thread lock, denoted as the third target thread, the fifth thread. When the third target thread, the fifth thread, acquires the second thread lock, it can exist in two states: being scheduled and not being scheduled. If the fifth thread acquires computing resources, it can be scheduled to execute the computing task after acquiring the second thread lock, and releases the second thread lock after completing the task. If the fifth thread cannot acquire computing resources for a long time due to low priority or other reasons, it may remain in an unscheduled state even if it acquires the second thread lock.

[0252] The fourth thread finds in the bitmap that the fifth thread, which is acquiring the second thread lock, is being scheduled, so the fourth thread can continue to wait to acquire the second thread lock.

[0253] When the fourth thread finds the fifth thread holding the second thread lock in the bitmap, and the fifth thread has acquired the lock but hasn't been scheduled, the fourth thread can add a third flag to the fifth thread. This third flag indicates that the fifth thread is a thread that needs to be scheduled first. The flag added by the fourth thread for the fifth thread allows the operating system to allocate computing resources to the fifth thread and prioritize its scheduling. Once the fifth thread acquires the computing resources allocated by the operating system, it can hold the second thread lock and execute its computational task as quickly as possible, releasing the lock as soon as it completes its task. In this way, the fourth thread can acquire the second thread lock quickly, reducing the time it spends waiting to acquire the lock and speeding up the overall application process.

[0254] In one specific implementation, the scheme for the fourth thread to search for the fifth thread that acquires the second thread lock in the bitmap may specifically include: the fourth thread searching for the sixth thread that is directly blocking the fourth thread; if the sixth thread that is directly blocking the fourth thread acquires the second thread lock, the sixth thread is used as the fifth thread; if the sixth thread that is directly blocking the fourth thread does not acquire the second thread lock, the fourth thread searching for the seventh thread that is directly blocking the sixth thread; if the seventh thread acquires the second thread lock, the seventh thread is used as the fifth thread.

[0255] It's important to clarify that the sixth thread directly blocking the fourth thread can be understood as the sixth thread being adjacent to the fourth thread in the waiting queue of the second thread lock, but preceding the fourth thread. The seventh thread directly blocking the sixth thread means that the seventh thread is adjacent to the sixth thread in the waiting queue of the second thread lock, but precedes the sixth thread. While the seventh thread is ahead of the fourth thread, it is not adjacent to the fourth thread; therefore, the seventh thread can be considered to be indirectly blocking the fourth thread.

[0256] In other implementations, the fifth thread searched by the fourth thread at different automatic wake-up times may be the same or different. Specifically, at the first automatic wake-up time, the fourth thread searches for the thread holding the lock that the second thread locked at the first automatic wake-up time, and this thread is designated as the fifth thread corresponding to the first automatic wake-up time. At the second automatic wake-up time, the fourth thread searches for the thread holding the lock that the second thread locked at the second automatic wake-up time, and this thread is designated as the fifth thread corresponding to the second automatic wake-up time. The fifth thread corresponding to the first automatic wake-up time and the fifth thread corresponding to the second automatic wake-up time may be the same thread or different threads.

[0257] For example, the fourth thread is thread 0. Thread 0 fails to acquire thread lock 1 and enters the waiting queue for thread lock 1.

[0258] In the first automatic wake-up moment, thread 0 is woken up by the timer. For example Figure 7 As shown in (a), the currently blocked thread 0 is found to be thread 1 in the bitmap. Thread 1 currently holds thread lock 1 and is not scheduled. Thread 0 wakes up thread 1 and marks thread 1 as a priority scheduling thread, so that the operating system will allocate computing resources to thread 1, which is marked as a priority scheduling thread, and thread 1 is scheduled first. After waking up thread 1, thread 0 continues to enter the sleep state.

[0259] At the second automatic wake-up time, thread 0 is woken up again by the timer. For example Figure 7 As shown in (b), the thread currently blocked by thread 0 in the bitmap is thread 4. Thread 4 is blocked by its predecessor thread, thread 3. Thread 3 is blocked by its predecessor thread, thread 2. Thread 2 has acquired the thread lock and has not been scheduled.

[0260] Thread 0 can wake up thread 2, allowing thread 2 to run first. Specifically, thread 0 can mark thread 2 as a priority scheduling thread, so that the operating system can allocate computing resources to thread 2, thus ensuring thread 2 is scheduled first. Furthermore, after waking up thread 2, thread 0 will return to a sleeping state.

[0261] Thread 0 will continue the aforementioned operations until it acquires a second thread, ends its sleep state, and enters the running state.

[0262] In one specific implementation, such as Figure 8 The diagram shown illustrates the flow chart of the thread scheduling method provided for electronic devices, detailing the specific scheduling process. Figure 8 As shown, the provided thread scheduling method mainly includes the following steps:

[0263] S801: The first thread requests the first thread lock.

[0264] The first thread can be any thread created by the operating system. When the first thread needs to access a memory resource, it requests and acquires the corresponding first-thread lock. For details, please refer to the specific implementation processes of S213 and S214 mentioned above, which will not be repeated here.

[0265] S802: The first thread attempts to acquire the first thread lock.

[0266] The first thread requests the first-thread lock and initially follows the fast lock-acquiring path, meaning it attempts to acquire the lock. If the lock is not currently held by another thread, the first thread can successfully acquire the lock. If the lock is currently held by another thread, the first thread's attempt to acquire the lock fails, and it enters the slow lock-acquiring path.

[0267] If the first thread successfully acquires the lock, it can proceed to step S803. If the first thread fails to acquire the lock, it enters the slow path and proceeds to step S804.

[0268] S803: If the first thread successfully acquires the lock, update the lock-holding thread identifier of the first thread to the first thread.

[0269] The first thread successfully acquires the lock, obtains the first-thread lock, and updates the lock-holding thread identifier of the first-thread lock to the first thread. In this way, other threads can query the lock-holding thread identifier of the first-thread lock to know that the current lock-holding thread is indeed the first-thread lock.

[0270] For details on how the first thread acquires the first thread lock, please refer to the specific implementation process in S215-S217 mentioned above. These details will not be repeated here.

[0271] S804: The first thread holds the first thread lock and executes the computation task.

[0272] The first thread holds the first-thread lock and executes the corresponding computational task. It should be noted that the computational task executed while the first thread holds the first-thread lock is not limited to all computational tasks executed during the first thread's runtime; it can refer to the computational tasks that need to be executed while the first thread holds the first-thread lock.

[0273] S805: The first thread clears the lock-holding thread identifier of the first thread lock.

[0274] Once the first thread has completed its computational task while holding the first thread lock, it begins the process of releasing the first thread lock. The first thread can first clear the lock-holding thread identifier to indicate that the current lock-holding thread is no longer the first thread.

[0275] S806: The first thread releases the first thread lock.

[0276] The first thread begins to release the first thread lock. Please refer to the specific implementation process of S218 mentioned above, which will not be repeated here.

[0277] S807: The first thread searches for the next second thread to request the lock held by the first thread.

[0278] The first thread releases the first thread lock and then searches for the next thread waiting to acquire the first thread lock, which is denoted as the second thread. The process of the first thread searching for the second thread can be referred to in the specific implementation process of S221-S223 mentioned above, and will not be repeated here.

[0279] S808: The second thread holds the lock for the first thread.

[0280] S809: The first thread updates the lock-holding thread identifier of the first thread lock to the second thread.

[0281] S810: The first thread wakes up the second thread, the second thread holds the lock of the first thread, and performs the computation task.

[0282] The second thread pre-acquires the lock from the first thread and updates the lock-holding thread identifier of the first thread to the second thread. After pre-acquiring the lock, the second thread enters the process of acquiring the lock from the first thread. The first thread wakes up the second thread, the second thread holds the lock from the first thread, and begins to execute the corresponding computation task.

[0283] The specific implementation process of the second thread attempting to acquire the lock of the first thread and starting to execute the computation task after successfully acquiring the lock can be found in the aforementioned specific implementation process of the first thread attempting to acquire the lock of the first thread, which will not be repeated here.

[0284] S811, the first thread updates the element values ​​of the corresponding region in the bitmap.

[0285] In the aforementioned S801, the step of the first thread requesting the first thread lock, the step of the first thread acquiring the first thread lock in S803, the step of the first thread releasing the first thread lock in S806, and the step of the second thread pre-holding the first thread lock in S808 all involve updating the element values ​​of the corresponding areas in the bitmap. For details, please refer to the specific implementation process of S212-S218 mentioned above, which will not be repeated here.

[0286] S812: If the first thread fails to acquire the lock, it enters the slow lock-waiting path and enters the first thread's lock waiting queue.

[0287] S813: The first thread enters a sleep state.

[0288] When the first thread requests the first thread lock, it attempts to acquire the lock. If the acquisition fails, it enters the slow lock-waiting path, enters the waiting queue of the first thread lock, and enters a sleep state.

[0289] S814: The first thread holds the first thread lock while in a sleep state.

[0290] The first thread waits in a sleep state to acquire the first thread lock. After a thread preceding the first thread acquires and releases the first thread lock, it will wake up the first thread to pre-acquire the first thread lock. The specific implementation process of the first thread pre-acquiring the first thread lock in the sleep state can be referred to in the aforementioned S807 and the specific implementation process of S221-S223, which will not be elaborated here.

[0291] S815: The lock-holding thread identifier of the first thread lock is updated to the identifier of the first thread.

[0292] S816: The first thread is awakened.

[0293] S817: The first thread attempts to acquire the first thread lock.

[0294] The preceding thread of the first thread wakes up the first thread and pre-acquires the lock of the first thread, updates the lock-holding thread identifier of the first thread to the identifier of the first thread, the preceding thread of the first thread wakes up the first thread, and the first thread attempts to acquire the lock of the first thread.

[0295] If the first thread successfully acquires the lock, it jumps to execute S803.

[0296] If the first thread fails to acquire the lock, the first thread executes S818: interrupt wake-up.

[0297] S819: The first thread was killed / exited.

[0298] As described in step S802 above, the first thread attempts to acquire the first thread lock. If the first thread successfully acquires the lock, the process jumps to S803, where the first thread acquires the first thread lock and executes the computation task. The first thread releases the first thread lock upon completion of the computation task.

[0299] In some situations, such as when the first thread is attempting to acquire a lock for writing, if the write lock is preempted by another thread that is also requesting the lock (read or write lock), the first thread's attempt to acquire the lock will fail. If the first thread fails to acquire the lock, it will not re-enter the lock's waiting queue. If the first thread is preempted for writing the lock and enters a sleep state, and receives a kill signal from the operating system, the first thread will be interrupted and awakened, and may be killed or exited.

[0300] like Figure 9 The diagram shown is a comparison of the effects of the thread scheduling method provided in the embodiments of this application. Figure 9As shown in (a) of this application, the main thread of the application is frequently blocked due to the failure to use the thread scheduling method provided in the embodiments of this application. After being blocked, the main thread can only passively wait for the lock-holding thread to release the lock. The lock-holding thread may not be scheduled for a long time due to its low priority, resulting in a long total blocking time for the main thread. Figure 9 As shown in (b) of this application, this diagram illustrates the effect of using the thread scheduling method provided in this embodiment. After the main thread is blocked, it actively searches for blockers based on the bitmap at regular intervals, marking them as tasks requiring priority scheduling. This way, the system will select the blocker when choosing tasks for execution next time. The total blocking time of the main thread is shortened.

[0301] The thread scheduling method provided in this embodiment quickly records the blocking relationships between threads using a bitmap, without requiring additional members to be added to the task structure. It is applicable to multiple types of thread locks and eliminates the need for periodic checks of the blocking status. The operating system can effectively identify and quickly schedule blocked threads, reducing application lag time.

[0302] Furthermore, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the processor runs an operating system;

[0303] The memory stores instructions that the computer executes;

[0304] The processor executes computer execution instructions stored in memory, causing the operating system to execute the thread scheduling method provided in the above embodiments. In addition to these main components, the electronic device also includes components for implementing basic functions, which will be discussed below. Figure 10 Please provide a detailed explanation.

[0305] like Figure 10 The diagram shown is a structural schematic of an electronic device 1000 provided in an embodiment of this application. The electronic device 1000 may include a processor 1010, a memory 1020, a Universal Serial Bus (USB) interface 1030, a charging management module 1040, a power management module 1041, a battery chip 1042, an antenna, a communication module 1050, a display screen 1060, an audio module 1070, a sensor module 1080, a camera 1090, etc.

[0306] The structure illustrated in this embodiment of the invention does not constitute a limitation on the electronic device 1000. It may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0307] Processor 1010 may include one or more processing units. For example, processor 1010 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0308] The processor 1010 described above can be the decision-maker that directs the various components of the electronic device 1000 to work in a coordinated manner according to instructions. It is the nerve center and command center of the electronic device 1000. The processor 1010 generates operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0309] The processor 1010 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 1010 is a cache memory, which can store instructions or data that the processor 1010 has just used or that are used repeatedly. If the processor 1010 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 1010, and thus improves the efficiency of the system.

[0310] In some embodiments, the processor 1010 may include interfaces. These interfaces may include an Inter-Integrated Circuit (I2C) interface, an Inter-Integrated Circuit Sound (I2S) interface, a Pulse Code Modulation (PCM) interface, a Universal Asynchronous Receiver / Transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI) interface, a General-Purpose Input / Output (GPIO) interface, a SIM interface, and / or a USB interface, etc.

[0311] The interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 1000. The electronic device 1000 may employ different interface connection methods or combinations of multiple interface connection methods as described in the embodiments of the present invention.

[0312] The charging management module 1040 can be a rechargeable battery or a disposable battery. When it is a rechargeable battery, it can receive charging input through a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 1040 can receive charging input from the wired charger through the USB interface 1030. In some wireless charging embodiments, the charging management module 1040 can receive wireless charging input through the wireless charging coil of the electronic device 1000. While charging the battery chip 1042, the charging management module 1040 can also supply power to the electronic device 1000 through the power management module 1041.

[0313] The power management module 1041 connects the battery chip 1042, the charging management module 1040, and the processor 1010. The power management module 1041 receives input from the battery chip 1042 and / or the charging management module 1040, providing power to the processor 1010, memory 1020, external memory interface, display 1060, camera 1090, and communication module 1050, etc. The power management module 1041 can also monitor parameters such as the charging management module capacity, charging management module cycle count, and charging management module health status (leakage current, impedance). In some embodiments, the power management module 1041 can also be located within the processor 1010. In some embodiments, the power management module 1041 and the battery chip 1042 can also be located in the same device.

[0314] The wireless communication function of the electronic device 1000 can be realized through an antenna, a communication module 1050, a modem, and a baseband processor.

[0315] Electronic device 1000 implements display functions through a GPU, display screen 1060, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 1060 and the application processor. The GPU performs mathematical and geometric calculations for graphics rendering. Processor 1010 may include one or more GPUs, which execute program instructions to generate or modify display information. Display screen 1060 is used to display images, videos, etc. Display screen 1060 includes a display panel. Electronic device 1000 can implement shooting functions through an ISP, camera 1090, video codec, GPU, display screen 1060, and application processor.

[0316] Electronic device 1000 can implement audio functions, such as music playback and recording, through the speaker, receiver, microphone, headphone jack, and application processor of audio module 1070.

[0317] The thread scheduling methods described in the foregoing embodiments can all be implemented in the electronic device 1000 with the aforementioned hardware structure.

[0318] Based on the above embodiments, this application also provides a thread scheduling device, which includes a processor for executing the thread scheduling method provided in the above embodiments.

[0319] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to execute the thread scheduling method provided in the above embodiments.

[0320] This application also provides a computer program product containing instructions that, when run on a computer, enable the computer to execute the thread scheduling method provided in the above embodiments.

[0321] The specific implementation methods and technical effects of the electronic devices, computer-readable storage media, and computer program products containing instructions provided in this application can be found in the specific implementation process and technical effects of the thread scheduling method provided in the foregoing embodiments, which will not be repeated here.

[0322] In some embodiments, as described above, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the division of the functional modules described above is merely an example. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0323] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0324] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0325] The above are merely specific embodiments of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the scope of the claims.

Claims

1. A thread scheduling method, characterized in that, Applied to an electronic device, the electronic device including an operating system, the thread scheduling method includes: The operating system searches for the first thread in the waiting queue of the first thread lock; wherein, the first thread refers to the thread in the waiting queue of the first thread lock that is blocked by other threads and needs to acquire the lock first, and the current thread holding the lock of the first thread lock is the second thread. The operating system adds a first flag to the first thread; The second thread releases the first thread lock, and the first thread with the first tag acquires the first thread lock; The fourth thread requests the second thread lock and enters the waiting queue of the second thread lock; the fourth thread has the function of automatically waking up at multiple automatic wake-up times; At each automatic wake-up time, the fourth thread searches for the fifth thread; wherein the fifth thread is the current lock-holding thread of the second thread lock, and the fifth thread directly or indirectly blocks the fourth thread; wherein, at the first automatic wake-up time, the fourth thread searches for the lock-holding thread of the second thread lock at the first automatic wake-up time, and selects it as the fifth thread corresponding to the first automatic wake-up time; at the second automatic wake-up time, the fourth thread searches for the lock-holding thread of the second thread lock at the second automatic wake-up time, and selects it as the fifth thread corresponding to the second automatic wake-up time. If the fifth thread is not scheduled, the fourth thread adds a third flag to the fifth thread; The operating system prioritizes scheduling the fifth thread, which has the third tag added.

2. The thread scheduling method according to claim 1, characterized in that, After the operating system searches for the first thread in the waiting queue of the first thread lock, the thread scheduling method further includes: If the first thread is not found, the operating system searches for a third thread in the waiting queue of the first thread lock; wherein, the third thread refers to the thread with the longest waiting time among all threads in the waiting queue of the first thread lock. The operating system adds a second flag to the third thread; The second thread releases the first thread lock, and the third thread, which has the second tag, acquires the first thread lock.

3. The thread scheduling method according to claim 1 or 2, characterized in that, The steps of the operating system adding a first flag to the first thread, the second thread releasing the first thread lock, and the first thread acquiring the first thread lock after the first flag has been added include: The operating system sets the priority lock-holding pointer to the first thread in the waiting queue of the first thread lock; wherein, the priority lock-holding pointer pointing to the first thread indicates that the first thread has added the first flag; When the second thread releases the first thread lock, the second thread wakes up the first thread pointed to by the priority lock-holding pointer so that the first thread can acquire the first thread lock.

4. The thread scheduling method according to claim 1, characterized in that, The fifth thread corresponding to the first automatic wake-up time and the fifth thread corresponding to the second automatic wake-up time can be the same thread or different threads.

5. The thread scheduling method according to claim 1, characterized in that, The steps for the fourth thread to find the fifth thread include: The fourth thread searches for the sixth thread, which directly blocks the fourth thread; If the sixth thread, which directly blocks the fourth thread, acquires the second thread lock, then the sixth thread is treated as the fifth thread. If the sixth thread, which directly blocks the fourth thread, fails to acquire the second thread lock, then search for the seventh thread, which directly blocks the sixth thread. If the seventh thread acquires the second thread lock, the seventh thread will be used as the fifth thread.

6. The thread scheduling method according to claim 1 or 5, characterized in that, Before the step of the fourth thread requesting the second thread lock and entering the waiting queue of the second thread lock, the thread scheduling method further includes: If the fourth thread is the main thread, the operating system configures a timer with a corresponding automatic wake-up function for the fourth thread. The timer sends a timed wake-up message to the fourth thread at each automatic wake-up time; the timed wake-up message is used to wake up the fourth thread at each automatic wake-up time.

7. The thread scheduling method according to claim 1, characterized in that, The electronic device stores a bitmap; wherein, the bitmap records the blocking relationships between all threads within the electronic device, the bitmap includes a row and column matrix, the element value of the m-th row and n-th column of the row and column matrix indicates the blocking relationship between thread m and thread n, the element value is a first value indicating no blocking between threads, the element value is a second value indicating blocking between threads, and m and n are both thread numbers; The thread scheduling method further includes: The operating system queries the element values ​​in the first target row corresponding to the first thread in the bitmap to obtain the blocking relationship between threads within the electronic device.

8. The thread scheduling method according to claim 7, characterized in that, The thread scheduling method further includes: The operating system creates the bitmap and sets the element values ​​in the bitmap to the first value; The eighth thread modifies the element values ​​in the bitmap based on the changes in the inter-thread blocking relationship; wherein, the eighth thread is the thread whose inter-thread blocking relationship has changed.

9. The thread scheduling method according to claim 8, characterized in that, The step of the eighth thread modifying the element values ​​in the bitmap according to the changes in the inter-thread blocking relationship includes: When the eighth thread requests the third thread lock at the first moment, it searches for the ninth thread; wherein, the ninth thread is all threads that blocked the eighth thread at the first moment, and the ninth thread includes the thread holding the third thread lock at the first moment and all threads in the waiting queue of the third thread lock; The eighth thread modifies the element values ​​of the second target columns corresponding to each ninth thread in the first target row of the bitmap to the second value.

10. The thread scheduling method according to claim 9, characterized in that, After the eighth thread modifies the element values ​​of the second target columns corresponding to the ninth thread in the first target row of the bitmap to the second value, the thread scheduling method further includes: When the eighth thread acquires the lock of the third thread at the second moment, the eighth thread modifies the element value of each of the second target columns in the first target row of the bitmap to the first value. The eighth thread searches for the tenth thread; wherein the tenth thread is all threads in the waiting queue of the third thread lock at the second moment; The eighth thread modifies the element value of the third target row corresponding to each of the tenth threads in the first target column of the bitmap to the second value.

11. The thread scheduling method according to claim 10, characterized in that, After the eighth thread modifies the element value of the third target row corresponding to each of the tenth threads in the first target column of the bitmap to the second value, the thread scheduling method further includes: When the eighth thread releases the first thread lock at the third moment, the eighth thread modifies the element value of each of the third target rows in the first target column of the bitmap to the first value.

12. The thread scheduling method according to any one of claims 7-11, characterized in that, The first value is 0, and the second value is 1.

13. An electronic device, characterized in that, The electronic device includes a memory and a processor, the operating system of the electronic device runs on the processor, and the memory is coupled to the processor; The memory stores computer-executed instructions; The operating system schedules the processor to execute computer execution instructions stored in the memory, causing the electronic device to execute the thread scheduling method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the thread scheduling method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, It includes a computer program, which, when executed by a processor, implements the thread scheduling method as described in any one of claims 1-12.

Images