Thread processing method and device

Abstract

The embodiment of the invention provides a thread processing method and device, relates to the technical field of computers, and can solve the problem of priority inversion in a conditional variable scene and improve the execution efficiency of threads. The method is applied to the electronic equipment, the electronic equipment comprises a target processor, the target processor comprises a target running queue, the target running queue comprises a first thread, a second thread and a third thread, and the method comprises the steps that under the condition that the condition of a target condition variable is not met, the first thread enters a sleep state, and the third thread enters a sleep state; the data is not cleared from the target operation queue; the condition of setting the target condition variable by the second thread is met, and the first thread is awakened; under the condition that the condition of the target condition variable is met, the first thread continues to run; after the first thread runs, the third thread runs, and the priority of the third thread is higher than that of the second thread and lower than that of the first thread.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a thread processing method and apparatus. Background Art

[0002] A condition variable is a synchronization mechanism in concurrent programming. It allows a thread to block until the condition of the condition variable is met before continuing execution.

[0003] In some cases, priority inversion may occur while a thread is waiting for the condition of a condition variable to be met.

[0004] For example, assuming that the thread waiting for the condition variable to be satisfied is a high-priority thread, and the thread causing the condition variable to be satisfied is a low-priority thread, then the high-priority thread needs to wait for the low-priority thread to satisfy the condition variable (i.e., for the condition variable to be satisfied). However, while the high-priority thread (e.g., thread A) is waiting for the low-priority thread (e.g., thread C) to satisfy the condition variable, another thread (e.g., thread B) may preempt the CPU resources of the low-priority thread (e.g., thread C). If the priority of the other thread is lower than that of the high-priority thread, a priority inversion problem may occur, i.e., a thread lower than the high-priority thread (e.g., thread B) executes before the high-priority thread (e.g., thread A), causing the high-priority thread to wait longer for the condition variable to be satisfied, thereby reducing the execution efficiency of the high-priority thread. Summary of the Invention

[0005] The embodiments of the present application provide a thread processing method and apparatus, which can solve the priority inversion problem in conditional variable scenarios and improve the execution efficiency of threads.

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

[0007] In a first aspect, a thread processing method is provided, which is applied to an electronic device, wherein the electronic device includes a target processor, the target processor includes a target run queue, the target run queue includes a first thread, a second thread, and a third thread, the method comprising: when a condition of a target condition variable is not met, the first thread enters a sleep state and is not cleared from the target run queue; the second thread sets a condition of the target condition variable to be met and wakes up the first thread; when the condition of the target condition variable is met, the first thread continues to run; after the first thread finishes running, the third thread runs, wherein the priority of the third thread is higher than the priority of the second thread and lower than the priority of the first thread.

[0008] Based on the method provided in an embodiment of the present application, when the condition of the target condition variable is not established, the first thread can enter a sleep state. After the first thread enters a sleep state, the target processor can run the second thread. In addition, since the first thread is not cleared from the target run queue, the thread (the third thread) with a lower priority than the first thread in the target run queue will not preempt CPU resources, and the third thread can be prevented from preempting the CPU resources of the second thread, so that the second thread can be executed smoothly, and the condition of the target condition variable is set as soon as possible, and then the first thread can continue to run. In this way, the duration of the conditions of the target condition variables such as the first thread being established can be reduced, and the execution efficiency of the first thread can be improved.

[0009] In one possible implementation, before the first thread enters a sleep state and is not cleared from the target run queue, the method further includes: the second thread writes the first information into the first parameter and wakes up the first thread; wherein the first parameter is used to indicate the holding thread of the target condition variable, and the first information includes the thread identifier of the second thread. After the first thread learns that the holding thread of the target condition variable is the second thread, it can enter a sleep state and not be cleared from the target run queue. Furthermore, the thread (the third thread) with a lower priority than the first thread in the target run queue will not preempt CPU resources, and the third thread can be prevented from preempting the CPU resources of the second thread, so that the second thread can be executed smoothly, and the condition of the target condition variable can be set as soon as possible, and then the first thread can continue to run. In this way, the time for the condition of the target condition variable such as the first thread to be established can be reduced, and the execution efficiency of the first thread can be improved.

[0010] In one possible implementation, after the second thread writes the first information into the first parameter and wakes up the first thread, the method further includes: after the first thread is awakened, reading the first information corresponding to the first parameter and writing the first information into the second parameter; and the first thread notifying the target processor based on the second parameter to run the second thread. It should be noted that because the first thread has not been cleared from the target run queue and is the highest-priority thread in the target run queue, the first thread can be selected by the target processor (also known as the scheduler) as the next thread to run (to be run). Furthermore, because the first thread enters a sleep state and is not actually running, the first thread can notify the target processor to run the second thread. The first thread can act as a proxy for the second thread, and the target processor actually runs the second thread. It should be understood that when the target processor actually runs the second thread, the first thread acts as a proxy for the second thread, meaning that the second thread runs under the "identity" of the first thread. In this case, the third thread cannot detect that the target processor is actually running the second thread and instead believes that the target processor is actually running the first thread. Because the first thread's priority is higher than that of the third thread, the third thread believes that the "first thread" is running and will not preempt CPU resources. The target processor is actually running the second thread, thus preventing the third thread from preempting the second thread's CPU resources. This ensures the smooth execution of the second thread, ensuring that the condition of the target condition variable is met, and allowing the first thread to continue running. This avoids the problem of the first thread waiting for an excessive amount of time due to the third thread preempting the second thread's CPU resources, thereby improving the execution efficiency of the first and second threads.

[0011] In one possible implementation, before the second thread writes the first information to the first parameter, the method further includes: the first thread reading the first parameter; and if the first parameter is null, entering a sleep state and clearing the target run queue. It should be understood that if the first parameter is null, it indicates that the holding thread of the target condition variable cannot be determined. In this case, the first thread can enter a sleep state and clear the target run queue, thereby avoiding the first thread remaining in the target run queue when the holding thread of the target condition variable cannot be determined, thereby wasting CPU resources.

[0012] In one possible implementation, after the condition for the second thread to set the target condition variable is met, the method further includes: the second thread clearing the first parameter. This prevents the next batch of threads waiting for the target condition variable from reading the wrong thread holding the target condition variable.

[0013] It is understandable that different threads can be the holding threads of the same condition variable in different time periods. For example, in the first time period, thread C can be the holding thread of the target condition variable, and the first parameter includes the information of thread C. In the second time period, thread D can be the holding thread of the target condition variable. At this time, if the first parameter still includes the information of thread C, it will cause the threads in the waiting queue of the target condition variable to be misjudged, mistakenly believing that thread C is the holding thread of the current target condition variable, while in fact, in the second time period, thread D is the holding thread of the target condition variable. Therefore, after thread C sets the condition of the target condition variable, it can immediately clear the first parameter, so that the next holding thread of the target condition variable (or the next thread that sets the condition of the target condition variable) can write its own information into the first parameter, avoiding the problem of misjudgment of the next batch of threads waiting for the target condition variable.

[0014] In one possible implementation, before the first thread continues to run, the method further includes: the first thread reads the first parameter, and if the first parameter is empty, clears the second parameter. This can avoid the first thread from misjudging the holding thread of other condition variables (condition variables different from the target condition variable) when waiting for the other condition variables, making the first thread unable to act as a proxy for the actual holding thread of the other condition variables, resulting in the actual holding thread of the other condition variables potentially having its CPU resources preempted by other threads, thereby causing the first thread to wait for an excessively long time.

[0015] In one possible implementation, the third thread joins the target run queue while the second thread is running. That is, the third thread joins the target run queue only after the second thread begins running. In this case, the first thread can act as a "proxy" for the second thread, so the third thread does not preempt the second thread's CPU resources.

[0016] In one possible implementation, the method further includes: before the first thread enters the sleep state, adding the first thread to a wait queue of a target condition variable; and waking up the first thread by the second thread includes: waking up the first thread based on the wait queue of the target condition variable. In this way, the second thread can accurately wake up the thread that needs to be woken up (e.g., the first thread) based on the wait queue.

[0017] In a second aspect, the present application provides a chip system, which comprises one or more interface circuits and one or more processors. The interface circuits and the processors are interconnected by wires. The chip system can be applied to an electronic device comprising a communication module and a memory. The interface circuit is configured to receive a signal from the memory of the electronic device and send the received signal to the processor, the signal comprising computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device can perform the method as described in the first aspect and any possible implementation thereof.

[0018] In a third aspect, the present application provides a computer readable storage medium comprising computer instructions. When the computer instructions are executed on an electronic device (such as a mobile phone), the electronic device performs the method as described in the first aspect and any possible implementation thereof.

[0019] In a fourth aspect, the present application provides a computer program product, which, when executed on a computer, causes the computer to perform the method as described in the first aspect and any possible implementation thereof.

[0020] In a fifth aspect, the embodiments of the present application provide a thread processing apparatus, which comprises a processor and a memory coupled to the processor. The memory stores program instructions, which, when executed by the processor, cause the apparatus to perform the method as described in the first aspect and any possible implementation thereof. The apparatus can be an electronic device or a server device, or can be a component of an electronic device or a server device, such as a chip.

[0021] In a sixth aspect, the embodiments of the present application provide a thread processing apparatus, which can be divided into different logical units or modules according to functions. Each unit or module performs different functions, so that the apparatus performs the method as described in the first aspect and any possible implementation thereof.

[0022] It can be understood that the chip system provided in the second aspect, the computer readable storage medium provided in the third aspect, the computer program product provided in the fourth aspect, and the apparatus provided in the fifth aspect and the sixth aspect can achieve the beneficial effects as described in the first aspect and any possible implementation thereof, which will not be described herein again. BRIEF DESCRIPTION OF DRAWINGS

[0023] Figure 1 A multi-thread execution timing diagram based on a mutex lock;

[0024] Figure 2 A multi-thread execution timing diagram based on a condition variable;

[0025] Figure 3 A schematic diagram of a multi-thread scheduling solution based on a mutex lock in related technology;

[0026] Figure 4 A schematic diagram of a multi-thread scheduling solution based on a mutex lock provided in an embodiment of the present application;

[0027] Figure 5 A flowchart of a thread processing method provided in an embodiment of the present application;

[0028] Figure 6 A schematic diagram of a multi-thread scheduling solution based on conditional variables provided in an embodiment of the present application;

[0029] Figure 7 A flowchart of another thread processing method provided in an embodiment of the present application;

[0030] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0031] Figure 9 A schematic structural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] To make the description of the following embodiments clear and concise, a brief introduction to the relevant concepts or technologies is first given:

[0033] Concurrent programming: running multiple threads "simultaneously" on a processor, each thread can perform corresponding tasks.

[0034] Threads need to schedule resources to execute tasks, that is, to obtain the right to use the central processing unit (CPU). In the scenario of multi-threaded execution, the CPU resource scheduling of each thread can be performed based on the time-sharing scheduling mechanism. For example, all threads take turns using the CPU, and the time each thread occupies the CPU (CPU resources) is evenly distributed. The time period that each thread occupies the CPU can be called a time slice. Alternatively, the CPU resources of each thread can be allocated based on the priority of each thread. For example, threads with high priority are given priority to use the CPU. If the priority of the threads is the same, then a thread will be randomly selected to use the CPU first and get priority to occupy the CPU time (CPU resources). Concurrent programming can improve the efficiency of program operation and make the CPU utilization rate higher.

[0035] Thread execution states: including new state (new), ready state / waiting for execution state (runnable), running state (running), blocked state (blocked) and dead state.

[0036] The newly created state refers to when a thread is created using the new operator (e.g., new Thread(r)), but the thread has not yet started running. A thread in the newly created state has not yet started running.

[0037] After creating a new thread, if you want to execute the thread, you can call the thread start() method. When the start() method returns, the thread is in the ready state, waiting for the processor to schedule it.

[0038] When the thread obtains the CPU time (obtains CPU resources), it enters the running state and executes the contents of the run() method.

[0039] During the running process of a thread, it may enter a blocked state for various reasons: for example, a thread calls sleep() to enter a dormant state / sleep state (sleep). The sleep state can include an interruptible sleep state (interruptible state for short) and an uninterruptible sleep state (uninterruptible state for short). Or, a thread calls an operation that is blocked on input / output (I / O) and is in an interrupted state (uninterrupt) before the I / O operation is completed. Or, a thread is blocked while waiting for a lock (mutex lock, read-write lock, etc.) to be released. Or, a thread is blocked while waiting for other triggering conditions, for example, a thread is blocked while waiting for a condition variable. The blocked state means that the running thread has not finished running, but has temporarily given up the CPU resources and is waiting to obtain the CPU resources next time.

[0040] There are several reasons why a thread may die: for example, the run() method ends normally; or an uncaught exception terminates the run() method and causes the thread to die suddenly.

[0041] Mutex: A synchronization mechanism in concurrent programming used to protect mutually exclusive access to shared resources in a multi-threaded environment. Mutex locks allow only one thread to operate / access shared resources (e.g., critical sections) at a time, while other threads need to wait. The thread that can operate shared resources (e.g., thread A) can be recorded as the thread holding the lock (i.e., the mutex lock). Thread A can be considered to hold the lock (lock), meaning that thread A is the owner of the lock. At this point, the remaining threads cannot operate the critical section, and these threads that cannot operate the critical section are called waiters of the lock. The waiter needs to wait until the owner finishes operating the critical section and releases the lock (unlock) before it can access the critical section.

[0042] Due to the mutual exclusion feature of the mutex lock (that is, when multiple threads access the same critical section, only the owner holding the lock can access the critical section), priority inversion problems may occur during thread execution.

[0043] For example, Figure 1 As shown, it is assumed that a low-priority thread (for example, thread C) holds the lock first and can operate the critical section. When a high-priority thread (for example, thread A) wants to operate the critical section, thread A needs to wait because the mutex lock is already held by thread C. However, while thread C is running, a medium-priority thread (for example, thread B) may preempt the CPU resources of the low-priority thread (for example, thread C). At this time, thread C needs to wait for thread B to release the CPU resources before it can continue to run. After thread C completes its operation, it releases the lock, and then thread A can hold the lock and operate the critical section. Because thread B preempts thread C's CPU resources, thread C waits, which in turn causes thread A to wait. Among them, the priority of thread A is greater than the priority of thread B, but the execution order of thread A is after thread B, that is, a priority inversion problem occurs.

[0044] Similarly, condition variables can also have priority inversion problems, that is, when a high-priority thread waits for a low-priority thread to complete its work, the CPU resources of the low-priority thread are preempted, causing a priority inversion problem.

[0045] For example, Figure 2 A multi-threaded execution timing diagram based on conditional variables is given. Figure 2 In the example, thread A is waiting for the condition variable to be satisfied, and thread A has a high priority. While thread A is waiting for the condition variable to be satisfied, thread C obtains CPU resources and executes its corresponding task. Thread C is the thread that can make the condition variable satisfy the condition. Ideally, thread C should complete its corresponding task, set the condition variable to satisfy the condition, and wake up thread A, allowing thread A to continue executing its corresponding task. However, in reality, because thread C has a low priority, it is possible that thread B, with a medium priority, may preempt CPU resources while thread C is executing its task. This preemption of CPU resources by thread B, with a medium priority, prioritizes its task, causing thread C to be unable to execute its task. Thread C must wait for thread B to complete its task and release CPU resources before it can regain CPU resources to execute its corresponding task and satisfy the condition variable. Thread C can then send a wake-up broadcast, which thread A receives and resumes its task.

[0046] Among them, while thread A is waiting for the condition variable to be met, thread C is blocked by the medium-priority thread B which preempts the CPU resources, causing the medium-priority thread B to execute before the high-priority thread A. That is, a priority inversion problem occurs, causing the high-priority thread A to wait longer for the condition variable to be met, reducing the execution efficiency of threads A and C.

[0047] In related technologies, solutions to the above-mentioned high priority inversion problem include priority inheritance and priority ceiling solutions.

[0048] The priority ceiling approach involves raising the priority of a thread to the highest priority among all threads that can access a shared resource. This highest priority is called the priority ceiling for that resource. With a priority ceiling, any thread accessing a shared resource will have its priority raised, potentially causing a lower-priority thread to block the execution of a higher-priority thread.

[0049] The priority inheritance scheme is to dynamically change the thread priority when a low-priority thread occupying a shared resource blocks a high-priority thread. For example, when a thread (e.g., thread A) requests / accesses a shared resource (e.g., S), if S is currently being used by thread C, thread A can compare thread C's priority with its own. If thread C's priority is lower than its own (i.e., thread A's) priority is raised to its own. After thread C releases resource S, thread A's original priority is restored.

[0050] Both the priority inheritance scheme and the priority ceiling scheme mentioned above require dynamically changing the thread priority. The embodiments of the present application provide a thread processing method that does not require changing the thread priority, can solve the priority inversion problem of mutex locks and the priority inversion problem of condition variables, can reduce the time that threads (e.g., high-priority threads) wait for condition variables, and improve the execution efficiency of threads.

[0051] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In the description of the present application, unless otherwise specified, "at least one" means one or more, and "a plurality of" means two or more than two. In addition, in order to facilitate the clear description of the technical solutions in the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0052] For the convenience of understanding, the thread processing method provided by the embodiments of the present application is specifically introduced below in combination with the drawings.

[0053] For example, it is assumed that the current run queue (abbreviated as rq) of the processor includes a high-priority thread (for example, thread A), a medium-priority thread (for example, thread B) and a low-priority thread (for example, thread C). As shown in Figure 3 In the original scheduling scheme of the linux kernel, when the high-priority thread (for example, thread A) wants to operate the critical section, if it is found that the mutex has been held by the low-priority thread (for example, thread C), the thread A can be taken off (i.e., removed from the run queue). At this time, the threads remaining in the run queue include thread B and thread C. When the CPU is scheduled, since the priority of thread B is higher than that of thread C, the CPU will select thread B to run, and thread C will be postponed to run, thereby prolonging the waiting time of thread A.

[0054] Still taking the example that the current run queue includes a high-priority thread (for example, thread A), a medium-priority thread (for example, thread B) and a low-priority thread (for example, thread C). As shown in Figure 4 In the thread processing method provided by the embodiments of the present application, when the high-priority thread (for example, thread A) wants to operate the critical section, even if it is found that the mutex has been held by the low-priority thread (for example, thread C), the thread A will not be taken off (i.e., removed from the run queue). In this way, when the CPU is scheduled, the thread A with the highest priority will be selected to run. However, thread A needs to wait for thread C to release the mutex, so it is only "on the surface" that thread A runs on the CPU. At this time, the CPU can actually run the low-priority thread C. That is, thread A can act as the "agent" of thread C. During the running of thread C, thread B "sees" the thread running on the CPU as thread A "on the surface" running on the CPU, rather than thread C actually running on the CPU. Since the priority of thread A is higher than that of thread B, thread B will not preempt the CPU resources of the actually running thread C, so that the smooth running of thread C can be ensured, thereby reducing the lock waiting time of thread A.

[0055] The above describes the method suitable for solving the mutex priority inversion problem. However, the above method for solving the mutex priority inversion problem cannot be directly applied to the condition variable to solve the priority inversion problem existing in the condition variable. This is because when a thread is waiting for the condition of the condition variable to be established, it is unknown which thread is the wake-up source. The wake-up source refers to the thread that makes the condition of the condition variable established, and the thread that makes the condition of the condition variable established can wake up the thread waiting for the condition variable.

[0056] Because the thread (for example, a high-priority thread, such as thread A) does not know which thread was the wakeup source, thread A is removed from the run queue. If the wakeup source is a low-priority thread (for example, thread C), thread A cannot delegate execution to thread C because it has been removed from the run queue. As a result, thread C may be preempted by another thread (for example, medium-priority thread B) for CPU resources.

[0057] The embodiments of the present application provide a thread processing method that can solve the priority inversion problem in condition variables.

[0058] The method provided herein is applicable to various types of condition variables. For example, these types of condition variables may include those in the Linux kernel, those in the ART virtual machine in the Android system, and those implemented using other methods. The underlying implementation of these condition variables may be based on the Linux kernel's futex lock.

[0059] like Figure 5 As shown, an embodiment of the present application provides a thread processing method, which is applied to an electronic device, the electronic device includes a target processor, the target processor includes a target run queue, the target run queue includes a first thread, a second thread and a third thread, the method comprising:

[0060] 501. The first thread waits for the condition of the target condition variable to be met.

[0061] During the process of the first thread executing the first task, when the execution state of the first thread does not meet the requirements of the target condition variable, the first thread can suspend the execution of the first task (or the first thread is suspended), enter the sleep state, and wait for the condition of the condition variable to be met (or the condition is true), and then the first thread can continue to execute.

[0062] The first task may be the main task of the first thread. For example, if the first thread is a drawing thread, the first task may be a drawing task. If the first thread is a rendering thread, the first task may be a rendering task. If the first thread is a compositing thread, the first task may be a compositing task, and so on.

[0063] Among them, the target condition variable can correspond to one or more parameters (also referred to as members or member variables). Exemplarily, the parameters of the target condition variable may include the condition flag bit (flag) of the target condition variable and the waiting queue of the target condition variable. Among them, the condition flag bit of the target condition variable can be used to indicate whether the condition of the target condition variable is established (whether it is satisfied), or in other words, the condition flag bit of the target condition variable can be used to indicate whether the condition of the target condition variable is true (true) or false (false). For example, when the condition flag bit of the target condition variable is 0 (i.e., flag=0), it indicates that the condition of the target condition variable is not established (i.e., the condition is false, the condition is not satisfied); when the condition flag bit of the target condition variable is 1 (i.e., flag=1), it indicates that the condition of the target condition variable is established (i.e., the condition is true, the condition is satisfied).

[0064] The waiting queue for the target condition variable may include information (e.g., thread identifiers) of threads waiting for the condition of the target condition variable to be met. Threads waiting for the condition of the target condition variable to be met may add themselves to (or hang up on) the waiting queue corresponding to the target condition variable. For example, a first thread may add itself to the waiting queue corresponding to the target condition variable. When a thread makes the condition of the target condition variable meet, the thread may send a wake-up notification to one or more threads in the waiting queue for the target condition variable to wake up the corresponding threads.

[0065] For example, thread A is the first thread and condition variable V is the target condition variable. Thread A waits for condition variable V. At this time, the condition flag bit V.flag corresponding to condition variable V is 0, indicating that the condition of condition variable V is not satisfied. The first thread can add itself to the waiting queue of condition variable V.

[0066] The target run queue of the target processor may refer to a run queue running on a CPU core. It is understood that the target processor (e.g., CPU) may include one or more cores (also referred to as CPU cores), and each CPU core may run a run queue. Each run queue may include one or more threads to be run. The threads in the run queue may have CPU resources allocated to them based on their priorities, and threads with higher priorities may use the CPU first (obtain CPU resources).

[0067] 502. The second thread wakes up the first thread.

[0068] Illustratively, the second thread is a thread that makes the condition of the target condition variable true.

[0069] In an embodiment of the present application, the parameters of the target condition variable may further include a first parameter, which is used to indicate the holding thread of the target condition variable, which may also be referred to as the owner. The holding thread of the target condition variable refers to a thread that can make the condition of the target condition variable true.

[0070] In some embodiments, the holding thread of the target condition variable may be a second thread. When the second thread obtains CPU resources and starts running, the first information may be written into the first parameter. The first information includes the thread identifier of the second thread. In addition, the second thread may check the waiting queue of the target condition variable. When the waiting queue of the target condition variable is not empty (that is, the waiting queue of the target condition variable includes one or more threads), the second thread may send a wake-up notification to one or more threads in the waiting queue of the target condition variable to wake up the threads in the waiting queue. When the threads in the waiting queue of the target condition variable include the first thread, the second thread may wake up the first thread.

[0071] In this way, when the holding thread of the target condition variable obtains CPU resources and starts running, it can write its own thread identifier into the first parameter and wake up one or more threads in the waiting queue of the target condition variable. In this way, the thread waiting for the condition of the target condition variable to be met can query the holding thread of the target condition variable based on the first parameter. Furthermore, the thread waiting for the condition of the target condition variable to be met can adopt a proxy execution solution, that is, it can act as a proxy for the holding thread of the target condition variable, so that the holding thread of the target condition variable can run on the CPU with its own "identity", thereby preventing other threads from preempting the CPU resources of the holding thread of the target condition variable.

[0072] In some embodiments, when the execution state of the first thread does not meet the requirements (conditions) of the target condition variable, the first thread can suspend the execution of the first task. In this case, the first thread can read the first parameter to determine the holding thread of the target condition variable. At this time, the second thread may not have obtained CPU resources yet, and therefore has not yet written the first information to the first parameter. Therefore, the first parameter read by the first thread is empty. When the first parameter is empty, the first thread can enter a sleep state and be cleared from the target run queue (or, removed / removed / taken off from the target run queue of the target processor). It should be understood that the first parameter is empty, indicating that the holding thread of the target condition variable cannot be determined at present. At this time, the first thread can enter a sleep state and be cleared from the target run queue to avoid the situation where the holding thread of the target condition variable cannot be determined, and the first thread still stays in the target run queue, resulting in a waste of CPU resources.

[0073] In some embodiments, the second thread can execute the second task to make the condition of the target condition variable true. That is, the condition of the target condition variable is true when the second thread finishes executing the second task. The execution of the second task by the second thread can be asynchronous with the execution of the first task by the first thread, and the order of the execution of the first task by the first thread and the execution of the second task by the second thread is not limited.

[0074] In some embodiments, the priority of the first thread is higher than the priority of the second thread. Therefore, the order of the execution of the first task by the first thread can be prior to the execution of the second task by the second thread.

[0075] 503、the first thread is woken up, and it is checked whether the condition of the target condition variable is true.

[0076] After the first thread is woken up, it can check (query) the condition flag of the target condition variable. For example, if the condition flag of the target condition variable is 0, it indicates that the condition of the target condition variable is not true (i.e. the condition is not met).

[0077] 504、if the condition of the target condition variable is not true, the first thread can enter a sleep state and is not removed from the target run queue.

[0078] In some embodiments, after the first thread is woken up, it can also read the first parameter. If the first information corresponding to the first parameter is read, the first information can be written into the second parameter. The second parameter is a parameter used by the first thread to record the holding thread of the current target condition variable.

[0079] If the first thread reads the first information corresponding to the first parameter, i.e. the first thread queries the holding thread of the target condition variable, the first thread can enter a sleep state and is not removed from the target run queue.

[0080] In addition, if the condition of the target condition variable is not true, the first thread can re-join (hang in) the waiting queue corresponding to the target condition variable.

[0081] 505、the target processor runs the second thread.

[0082] In some embodiments, after the first thread enters the sleep state, the target processor can run the second thread, i.e. the second thread can run on the target processor. For example, after the first thread enters the sleep state, if the target run queue of the target processor includes the second thread, and the second thread is the thread with the highest priority except the first thread, after the first thread enters the sleep state, the target processor can run the second thread.

[0083] In other embodiments, the first thread can notify the target processor to run the second thread.

[0084] It should be noted that, since the first thread has not been cleared from the target run queue and is the highest-priority thread in the target run queue, the first thread can be selected by the target processor (also known as the scheduler) as the next thread to run (to be run). Furthermore, since the first thread has entered a sleep state and is not actually running, the first thread can notify the target processor to run the second thread. The first thread can act as a proxy for the second thread, and the target processor can actually run the second thread.

[0085] The first thread may notify the target processor to run the second thread based on the second parameter. Exemplarily, the first thread may send the memory address of the second thread to the target processor so that the target processor runs the second thread.

[0086] It should be noted that when the second thread is running on the target processor, the CPU resources of the second thread will not be preempted by the third thread. Among them, the priority of the third thread is higher than the priority of the second thread, and lower than the priority of the first thread.

[0087] It should be understood that when the target processor is actually running the second thread, the first thread is a proxy for the second thread, that is, the second thread is running under the "identity" of the first thread. In this case, the third thread cannot discover that the target processor is actually running the second thread, and will think that the target processor is actually running the first thread. Since the priority of the first thread is higher than that of the third thread, the third thread will not preempt CPU resources when it believes that the "first thread" is running. Since the target processor is actually running the second thread, the third thread can be prevented from preempting the CPU resources of the second thread. This ensures that the second thread runs smoothly, so that the condition of the target condition variable is met, and the first thread can continue to run, avoiding the problem of the first thread waiting for too long due to the third thread preempting the CPU resources of the second thread, and can improve the execution efficiency of the first and second threads.

[0088] 506. When the condition of the target condition variable is satisfied, the second thread wakes up the first thread.

[0089] In some embodiments, when the second thread completes executing the second task, the condition of the target condition variable is met.

[0090] Exemplarily, the second thread may set the condition flag bit of the target condition variable to a preset value (eg, 1), indicating that the condition of the target condition variable is met.

[0091] Furthermore, when the second thread makes the condition of the target condition variable true, the thread in the waiting queue of the target condition variable (for example, the first thread) can be awakened so that the thread in the waiting queue of the condition variable can continue to execute.

[0092] In some embodiments, after the second thread wakes up the threads in the waiting queue of the target condition variable, the first parameter can be cleared in the case that the second thread makes the condition of the target condition variable true. In this way, other threads waiting for the target condition variable can be prevented from reading the wrong thread holding the target condition variable. It can be understood that different threads can be the thread holding the same condition variable at different time periods. For example, at a first time period, thread C can be the thread holding the target condition variable, and at this time, the first parameter includes the information of thread C. At a second time period, thread D can be the thread holding the target condition variable, and if the first parameter still includes the information of thread C, the threads in the waiting queue of the target condition variable can be mistaken that thread C is the thread holding the target condition variable at the current time period, while in fact, thread D is the thread holding the target condition variable at the second time period. Therefore, thread C can clear the first parameter immediately after setting the condition of the target condition variable to true, so that the next thread holding the target condition variable (or the next thread setting the condition of the target condition variable to true) can write its own information into the first parameter, and the next batch of threads waiting for the target condition variable can be prevented from being mistaken.

[0093] In some embodiments, after the second thread wakes up all the threads in the waiting queue of the target condition variable in the case that the second thread makes the condition of the target condition variable true, the waiting queue of the target condition variable can be cleared. In this way, the next thread holding the target condition variable can be prevented from mistakenly waking up the threads that do not need to wait for the target condition variable to be true.

[0094] 507、The first thread can continue running after being woken up.

[0095] After being woken up, the first thread can first check whether the condition of the target condition variable is true. In the case that the condition of the target condition variable is true, the first thread can continue running. For example, if the first thread queries that the condition flag of the target condition variable is set to a preset value (e.g., flag = 1), it is considered that the condition of the target condition variable is true, and the first thread can continue running (e.g., continue to execute the first task that is paused before).

[0096] In some embodiments, before the first thread continues running after being woken up, the first thread can read the first parameter, and clear the second parameter in the case that the first parameter is empty. In this way, the first thread can be prevented from mistakenly judging the thread holding another condition variable (a condition variable different from the target condition variable) when waiting for the other condition variable, so that the first thread cannot act as the agent of the real thread holding the other condition variable, and the real thread holding the other condition variable can be preempted by other threads, thereby causing the problem of long waiting time of the first thread.

[0097] 508. After the first thread finishes running, the target processor schedules the third thread to run.

[0098] Referring to the relevant description above (the description of step 505), it can be seen that the second thread runs on the target processor with the "identity" of the first thread. Therefore, when the second thread is running, the third thread thinks that the "first thread" is running. Since the priority of the first thread is higher than the priority of the third thread, the third thread will not preempt CPU resources. In this way, the second thread can be guaranteed to run smoothly so that the condition of the target condition variable is met, and then the first thread can continue to run, avoiding the problem of the first thread waiting for too long due to the third thread preempting the CPU resources of the second thread. After the first thread has finished running (for example, the execution of the first task is completed), the third thread can run. That is, after the second thread and the first thread have finished running, the third thread runs.

[0099] In some embodiments, the third thread is added to the target run queue while the second thread is running. That is, the third thread is added to the target run queue after the second thread begins running. In this case, even though the third thread has a higher priority than the second thread, the third thread will not preempt the second thread's CPU resources.

[0100] Based on the method provided in an embodiment of the present application, when the condition of the target condition variable is not established, the first thread can enter a sleep state. After the first thread enters a sleep state, the target processor can run the second thread. In addition, since the first thread is not cleared from the target run queue, the thread (the third thread) with a lower priority than the first thread in the target run queue will not preempt CPU resources, and the third thread can be prevented from preempting the CPU resources of the second thread, so that the second thread can be executed smoothly, and the condition of the target condition variable is set as soon as possible, and then the first thread can continue to run. In this way, the duration of the conditions of the target condition variables such as the first thread being established can be reduced, and the execution efficiency of the first thread can be improved.

[0101] The following describes the thread processing method provided in the embodiment of the present application by taking the first thread as thread A, the second thread as thread C, and the third thread as thread B as an example.

[0102] like Figure 6As shown, the target run queue may include threads A, B, and C. Assume that thread A is a high-priority thread, thread B is a medium-priority thread, and thread C is a low-priority thread. That is, thread A has a higher priority than thread B, and thread B has a higher priority than thread C. When thread A waits for a target condition variable, if the condition of the target condition variable fails to hold, thread A is not cleared from the target run queue (i.e., remains in the target run queue). Since thread A is the highest-priority thread in the target run queue, the target processor selects thread A as the next thread to run when scheduling threads. Since the condition of the target condition variable fails to hold, thread A does not actually run. Instead, it acts as a proxy for thread C. That is, thread A can notify the target processor to run thread C. In this case, the target processor actually runs thread C, not thread A. Since thread C runs on the target processor as thread A, when thread C runs, thread B thinks it is "thread A" that is running. Since thread A's priority is higher than thread B's, thread B does not preempt CPU resources. In this way, thread C can be guaranteed to run smoothly, so that the condition of the target condition variable is met, and thread A can continue to run, avoiding the problem of thread A waiting for too long due to thread B preempting thread C's CPU resources.

[0103] like Figure 7 As shown, the thread processing method provided by the embodiment of the present application is described by taking the first thread as thread A, the second thread as thread C, the third thread as thread B, and the target condition variable as condition variable V as an example. Thread A is the thread waiting for condition variable V to be established, and thread C is the thread that makes condition variable V established. The method includes:

[0104] 701. The target CPU selects thread A to run.

[0105] The target CPU may include a target run queue, which may include thread A, thread B, and thread C. The priority of thread A is higher than the priority of thread B, and the priority of thread B is higher than the priority of thread C. Since thread A is the thread with the highest priority in the target run queue, the target CPU may select thread A to run.

[0106] 702. Thread A obtains CPU resources and checks the condition flag bit of the condition variable V (eg, V.flag).

[0107] Exemplarily, the parameters corresponding to the condition variable V may include a condition flag bit of the condition variable V (e.g., V.flag), a waiting queue of the condition variable V (e.g., V.waiter_list), and a first parameter (e.g., V.owner). V.flag is used to indicate whether the condition variable V is true. V.owner is used to indicate the holding thread of the condition variable V, which may also be referred to as the owner. The holding thread of the condition variable V refers to a thread that can make the condition of the condition variable V true. V.waiter_list is used to indicate information (e.g., thread identifier) ​​of threads waiting for the condition of the target condition variable to be true.

[0108] For example, in step 702, the values ​​of the parameters of the conditional variable V may be as follows:

[0109] V.flag = 0, V.owner = NULL (i.e. empty), V.waiter_list = empty;

[0110] That is, the condition of the condition variable V is not met; the thread holding the condition variable V is NULL (ie, empty), and the thread waiting for the condition of the target condition variable to be met is NULL (ie, empty).

[0111] 703. When V.flag indicates that the condition variable V is not satisfied, thread A reads the first parameter of the condition variable V (eg, V.owner).

[0112] For example, if V.flag=0, it means that the condition variable V is not satisfied, and if V.flag=1, it means that the condition variable V is satisfied.

[0113] Thread A can read the first parameter (e.g., V.owner) to determine the owner of the condition variable V. If the first parameter read by thread A is null, that is, if the owner of the condition variable V is not found, thread A can set the second parameter (e.g., A.owner) to null. A.owner is a parameter used by thread A to record the owner of the current target condition variable (i.e., condition variable V).

[0114] 704. When no thread holding the condition variable V is found, thread A joins the waiting queue (V.waiter_list) of the condition variable V.

[0115] Thread A joins the waiting queue of the condition variable V so that when the condition of the condition variable V is satisfied by other threads (for example, thread C), thread A can be awakened again based on the waiting queue of the condition variable V.

[0116] For example, after thread A joins V.waiter_list, the values ​​of the parameters of the condition variable V can be as follows:

[0117] V.flag=0, V.owner=empty, V.waiter_list=A;

[0118] That is, the condition of the condition variable V is not met; the holding thread of the condition variable V is empty, and the threads waiting for the condition of the target condition variable to be met include thread A.

[0119] 705. When V.owner is empty, thread A enters sleep state and is cleared from the target run queue of the target CPU.

[0120] That is, thread A gives up the CPU, or thread A gives up the execution right of the CPU.

[0121] 706. The target CPU selects thread C to run.

[0122] The target CPU may select a thread (eg, thread C) other than thread A from the target run queue to run.

[0123] In some embodiments, the target run queue currently includes only thread A and thread C, so the target CPU can select thread C to run.

[0124] In other embodiments, the target run queue includes thread A, thread C, and threads with lower priority than thread C. In this case, the target CPU may still select thread C to run.

[0125] In some other embodiments, the target run queue includes thread A, thread C, and a thread with a higher priority than thread C (e.g., thread D). In this case, the target CPU may first select the thread with a higher priority than thread C (e.g., thread D) to run, and then may select thread C to run.

[0126] 707. Thread C obtains CPU resources and writes thread C information to V.owner.

[0127] Thread C is the thread that makes the condition of condition variable V true. When thread C obtains CPU resources and starts running, it can write its own information (for example, thread ID) into V.owner.

[0128] For example, after thread C writes thread C information to V.owner, the values ​​of the parameters of the condition variable V can be as follows:

[0129] V.flag=0, V.owner=C, V.waiter_list=A;

[0130] That is, the condition of the condition variable V is not met; the thread holding the condition variable V is thread C, and the threads waiting for the condition of the target condition variable to be met include thread A.

[0131] 708. Thread C wakes up thread A.

[0132] Thread C can query the waiting queue of condition variable V, and if the waiting queue of condition variable V is not empty, wake up the threads in the waiting queue of condition variable V. Since the waiting queue of condition variable V includes thread A, thread C can wake up thread A.

[0133] 709. Thread A seizes the CPU and checks V.flag and V.owner.

[0134] Since thread A has a higher priority than thread C, thread A can preempt the CPU to run.

[0135] When V.flag still indicates that the condition variable V is not satisfied, thread A queries V.owner again.

[0136] Thread A can read V.owner to determine the owning thread of the condition variable V.

[0137] If V.owner is not empty, A.owner can be set based on the information in V.owner. For example, if V.owner corresponds to thread C's information, thread A can write thread C's information to A.owner. This means that thread A can determine that the owner of condition variable V is thread C.

[0138] Moreover, when V.flag still indicates that the condition variable V is not satisfied, thread A can add itself to the waiting queue of the condition variable V again. So that when other threads (for example, thread C) make the condition of the condition variable V satisfied, thread A can be woken up again based on the waiting queue of the condition variable V.

[0139] 710. Thread A notifies the target CPU to run thread C based on A.owner.

[0140] Thread A can send the memory address of thread C to the target CPU so that the target CPU can run thread C.

[0141] That is, thread A can act as a proxy for thread C, allowing the CPU to actually run thread C.

[0142] 711. Thread A enters sleep state and is not cleared from the target run queue.

[0143] When V.flag indicates that the condition variable V is not true and V.owner is not empty, thread A enters the sleep state and is not cleared from the target run queue.

[0144] 712. The target CPU selects thread C to run.

[0145] 713. Thread C obtains CPU resources and executes the second task.

[0146] Thread C may execute the second task to make the condition of condition variable V true.

[0147] 714. Thread C completes the second task and sets V.flag=1.

[0148] 715. Thread C wakes up thread A again.

[0149] Thread C can wake up thread A again based on the waiting queue of condition variable V.

[0150] After thread C wakes up thread A, it can clear V.owner and V.waiter_list.

[0151] 716. After thread A is awakened, it checks V.flag.

[0152] 717. When V.flag=1, thread A continues to execute subsequent tasks.

[0153] Alternatively, thread A can clear A.owner.

[0154] 718. After thread A finishes running, the target processor schedules thread B to run.

[0155] The priority of thread B is higher than the priority of thread C, but lower than the priority of thread A.

[0156] In the embodiment of the present application, thread A can act as a proxy for thread C, that is, thread C runs on the target CPU with the "identity" of thread A. Therefore, when thread C is running, thread B thinks that "thread A" is running. Since the priority of thread A is higher than the priority of thread B, thread B will not preempt CPU resources. In this way, thread C can be guaranteed to run smoothly so that the condition of the target condition variable is met, and then thread A can continue to run, avoiding the problem of thread A waiting for too long due to thread B preempting the CPU resources of thread C. After thread A has finished running (that is, the execution of the first task is completed), thread B can run. That is, after thread C and thread A have finished running, thread B runs.

[0157] In some embodiments, thread B is added to the target run queue while thread C is running. That is, thread B is added to the target run queue after thread C starts running. In this case, even though thread B has a higher priority than thread C, thread B will not preempt thread C's CPU resources.

[0158] Based on the method provided by the embodiment of the present application, when the condition of the condition variable V is not established, thread A can enter a sleep state. Since thread A enters a sleep state, the target CPU can run thread C. Moreover, since thread A is not cleared from the target run queue, threads with a lower priority than thread A in the target run queue (for example, thread B) will not preempt CPU resources, which can prevent thread B from preempting the CPU resources of thread C, so that thread C can be executed smoothly and the condition of the target condition variable is set as soon as possible, and then thread A can continue to run. In this way, the duration for the conditions of the target condition variables such as thread A to be established can be reduced, and the execution efficiency of thread A can be improved.

[0159] The method provided by the embodiment of the present application has stronger generalization than schemes such as priority inheritance and priority ceiling, that is, it can be applied to a wider range of scenarios. Schemes such as priority inheritance and priority ceiling solve the high priority inversion problem by increasing the priority of low-priority threads, and are only applicable to scenarios where CPU resources of each thread are allocated based on the priority of each thread. The method provided by the embodiment of the present application uses a high-priority thread (for example, thread A) as a proxy for a low-priority thread (for example, thread C). In the scenario where CPU resources of each thread are allocated based on the priority of each thread, other threads (medium-priority threads, for example, thread B) can be prevented from preempting the CPU resources of the low-priority thread, thereby solving the high priority inversion problem. Moreover, in the scenario where CPU resources of each thread are scheduled based on a time-sharing scheduling mechanism, using a high-priority thread as a proxy for a low-priority thread allows the low-priority thread to run not only in its own corresponding time slice, but also in the time slice corresponding to the high-priority thread. In this way, the operating efficiency of the low-priority thread can be improved, ensuring that the low-priority thread runs smoothly, and thus reducing the waiting time of the high-priority thread.

[0160] The method provided in the above embodiment can be applied to electronic devices. Figure 8 A schematic structural diagram of an electronic device 100 provided in an embodiment of the present application.

[0161] like Figure 8As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0162] Among them, the sensor module 180 can include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0163] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0164] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a 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.

[0165] As an embodiment, the processor 110 may include one or more CPUs, and the target processor may be one of these CPUs.

[0166] In an embodiment of the present application, the target processor can allocate resources to each thread based on the priority of each thread. A target run queue can be run on the target processor, and the target run queue can refer to a run queue running on a CPU core. It is understandable that a processor (e.g., a CPU) can include one or more cores (also referred to as CPU cores), and a run queue can be run on each CPU core. Each run queue can include multiple threads to be run. The threads in the run queue can allocate CPU resources to each thread based on the priority of each thread, and threads with high priority can use the CPU first (obtain CPU resources).

[0167] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0168] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0169] In some embodiments, the processor 110 may include one or more interfaces. The 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), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface.

[0170] It is understood that the interface connection relationship between the modules illustrated in this embodiment is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0171] The charging management module 140 is configured to receive charging input from a charger. While charging the battery 142 , the charging management module 140 can also power the electronic device through the power management module 141 .

[0172] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160. In some other embodiments, the power management module 141 may also be provided in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may also be provided in the same device.

[0173] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0174] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network.

[0175] The mobile communication module 150 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low-noise amplifier (LNA), and the like. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, filter and amplify the received electromagnetic waves, and transmit them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signals modulated by the modem processor and convert them into electromagnetic waves for radiation via the antenna 1.

[0176] The modem processor may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium- or high-frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor outputs sound signals through an audio device (including but not limited to the speaker 170A, the receiver 170B, etc.) or displays images or videos through the display screen 194.

[0177] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0178] In some embodiments, the antenna 1 and the mobile communication module 150 of the electronic device 100 are coupled, and the antenna 2 and the wireless communication module 160 are coupled, so that the electronic device 100 can communicate with a network and other devices through wireless communication technology. The wireless communication technology can include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS can include a global positioning system (GPS), a global navigation satellite system (GLONASS), a beidu navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and / or a satellite based augmentation systems (SBAS).

[0179] The electronic device 100 implements a display function through a GPU, a display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, which is connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 can include one or more GPUs, which execute program instructions to generate or change display information.

[0180] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), a light-emitting diode (LED), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED).

[0181] The electronic device 100 can realize the shooting function through the ISP, camera 193, video codec, GPU, display screen 194 and application processor. The ISP is used to process the data fed back by the camera 193. The camera 193 is used to capture still images or videos. The digital signal processor is used to process digital signals. In addition to processing digital image signals, it can also process other digital signals. The video codec is used to compress or decompress digital videos. The electronic device 100 can support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0182] The cameras 193 may include 1 to N cameras. For example, the electronic device may include 2 front cameras and 4 rear cameras. The NPU is a neural network (NN) computing processor that quickly processes input information by drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, and can also continuously self-learn. The NPU can realize applications such as intelligent cognition of the electronic device 100, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0183] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are saved in the external memory card. The internal memory 121 can be used to store computer executable program code, and the executable program code includes instructions. The processor 110 can execute various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 can execute instructions stored in the internal memory 121, and the internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0184] The electronic device 100 can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0185] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. The speaker 170A, also known as a "speaker," is used to convert audio electrical signals into sound signals. The receiver 170B, also known as a "handset," is used to convert audio electrical signals into sound signals. The microphone 170C, also known as a "microphone" or "microphone," is used to convert sound signals into electrical signals. The headphone jack 170D is used to connect wired headphones.

[0186] The buttons 190 include a power button, a volume button, etc. The buttons 190 can be mechanical buttons. They can also be touch buttons. The electronic device 100 can receive button inputs and generate key signal inputs related to the user settings and function controls of the electronic device 100. The motor 191 can generate vibration prompts. The motor 191 can be used for incoming call vibration prompts or for touch vibration feedback. The indicator 192 can be an indicator light that can be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or removing it from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0187] The methods in the above embodiments can all be implemented in the electronic device 100 having the above hardware structure.

[0188] Some embodiments of the present application provide an electronic device, which may include: a touch screen, a memory, and one or more processors. The touch screen, the memory, and the processor are coupled. The memory is used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device can perform the various functions or steps performed by the electronic device in the above method embodiment. The structure of the electronic device can refer to Figure 8 The structure of the electronic device 100 is shown.

[0189] The present application also provides a chip system (eg, a system on a chip (SoC)). Figure 9 As shown, the chip system includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 can be interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (such as a memory of an electronic device). For another example, the interface circuit 902 can be used to send signals to other devices (such as a processor 901 or a touch screen of an electronic device). Exemplarily, the interface circuit 902 can read instructions stored in the memory and send the instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can execute the various steps in the above embodiments. Of course, the chip system can also include other discrete components, which are not specifically limited in the embodiments of the present application.

[0190] The embodiment of the present application further provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above electronic device, the electronic device executes the electronic device in the above method embodiment (for example, Figure 8 The various functions or steps performed by the electronic device 100 shown in FIG.

[0191] The present application also provides a computer program product. When the computer program product is run on an electronic device, the electronic device is enabled to execute the electronic device (for example, Figure 8 The various functions or steps performed by the electronic device 100 shown in FIG.

[0192] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions 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.

[0193] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0194] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0195] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0196] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium, including a plurality of instructions to make a device (which can be a single-chip microcomputer, a chip, etc.) or a processor execute all or part of the steps of the method described in various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0197] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any change or replacement within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A thread processing method, characterized in that: Applied to an electronic device, the electronic device includes a target processor, the target processor includes a target run queue, the target run queue includes a first thread, a second thread, and a third thread, the method includes: If the condition of the target condition variable is not satisfied, the first thread enters a sleep state and is not cleared from the target run queue; The second thread sets a condition for the target condition variable to be met, and wakes up the first thread; When the condition of the target condition variable is met, the first thread continues to run; After the first thread finishes running, the third thread runs, wherein the priority of the third thread is higher than the priority of the second thread and lower than the priority of the first thread.

2. The method according to claim 1, characterized in that Before the first thread enters a sleep state and is not cleared from the target run queue, the method further includes: The second thread writes the first information into the first parameter and wakes up the first thread; The first parameter is used to indicate the holding thread of the target condition variable, and the first information includes the thread identifier of the second thread.

3. The method according to claim 2, characterized in that After the second thread writes the first information into the first parameter and wakes up the first thread, the method further includes: After the first thread is awakened, the first information corresponding to the first parameter is read and the first information is written into the second parameter; The first thread notifies the target processor to execute the second thread based on the second parameter.

4. The method according to claim 2, characterized in that Before the second thread writes the first information into the first parameter, the method further includes: The first thread reads the first parameter; When the first parameter is empty, the program enters a sleep state and is cleared from the target run queue.

5. The method according to claim 2, characterized in that After the condition for the second thread to set the target condition variable is met, the method further includes: The second thread clears the first parameter.

6. The method according to claim 3, characterized in that Before the first thread continues to run, the method further includes: The first thread reads the first parameter, and clears the second parameter when the first parameter is empty.

7. The method according to any one of claims 1 to 6, characterized in that The third thread is added to the target execution queue during the execution of the second thread.

8. The method according to any one of claims 1 to 6, characterized in that The method further comprises: Before the first thread enters the sleep state, adding the first thread to the waiting queue of the target condition variable; The second thread waking up the first thread includes: The second thread wakes up the first thread based on the wait queue of the target condition variable.

9. An electronic device, characterized in that: The electronic device comprises: a wireless communication module, a memory and one or more processors; the wireless communication module, the memory and the processor are coupled; The memory is used to store computer program code, and the computer program code includes computer instructions; when the computer instructions are executed by the processor, the electronic device executes the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that including computer instructions; When the computer instructions are executed on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 8.

Images