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 read-write lock 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 operation queue, the target operation queue comprises a first thread, a second thread and a third thread, and the method comprises the steps that under the condition that the first thread holds a read lock of a target resource, the second thread enters a sleep state and is not cleared from the target operation queue; under the condition that the first thread releases the read lock of the target resource, the second thread is awakened and holds the write lock of the target resource; after the second thread runs, the third thread runs, and the priority of the third thread is lower than that of the second thread and higher 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 read-write lock is a synchronization mechanism used in concurrent programming. A read-write lock can be in two states: read and write. When the read-write lock is in the read state, the thread holding the lock (called the reader thread or "reader") can read the shared resource. When the read-write lock is in the write state, the thread holding the lock (called the writer thread or "writer") can write to the shared resource.

[0003] A read-write lock allows multiple read threads to read a shared resource simultaneously (for a period of time). However, a read-write lock allows only one write thread to write to the shared resource. That is, during the same period, multiple read threads or a single write thread may be accessing the shared resource. When multiple read threads are reading a shared resource, the thread requesting a write operation must wait for all read threads to release their read locks. This can lead to priority inversion.

[0004] For example, suppose the thread requesting a write operation on a shared resource is a high-priority thread, and one of the multiple read lock threads is a low-priority thread. While the low-priority thread is reading the shared resource, another thread (e.g., a medium-priority thread) may preempt the low-priority thread's CPU resources. In this case, the medium-priority thread executes before the high-priority thread, causing the high-priority thread to wait longer and reducing its execution efficiency. Summary of the Invention

[0005] The embodiments of the present application provide a thread processing method and device, which can solve the priority inversion problem in read-write lock 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, and the method includes: when the first thread holds a read lock of a target resource, the second thread enters a sleep state and is not cleared from the target run queue; when the first thread releases the read lock of the target resource, the second thread is awakened and holds a write lock of the target resource; after the second thread finishes running, the third thread runs, and the priority of the third thread is lower than the priority of the second thread and higher than the priority of the first thread.

[0008] Based on the method provided in the embodiment of the present application, when the first thread holds the read lock of the target resource, the second thread can enter the sleep state. After the second thread enters the sleep state, the target processor can run the first thread. Moreover, since the second thread is not cleared from the target run queue, the thread (third thread) with a lower priority than the second thread in the target run queue will not preempt CPU resources at this time, so that the third thread can avoid preempting the CPU resources of the first thread, so that the first thread can execute smoothly and release the read lock as soon as possible. Furthermore, the second thread can hold the write lock as soon as possible, which can reduce the time the second thread waits for the write lock and improve the execution efficiency of the second thread.

[0009] In one possible implementation, before the second thread enters a sleep state and is not cleared from the target run queue, the method further includes: the second thread reading a first parameter or a second parameter, the first parameter being used to indicate at least one thread holding a read lock on the target resource, the at least one thread being arranged in chronological order based on the time at which the read lock on the target resource was held, and the at least one thread including the first thread; and the second parameter being used to indicate a first target thread, the first target thread being the thread that held the read lock on the target resource the latest among the at least one threads. That is, after the second thread learns of the thread holding the read lock on the target resource, it can enter a sleep state and not be cleared from the target run queue. After the second thread enters a sleep state, the target processor can execute the first thread. Furthermore, since the second thread is not cleared from the target run queue, threads with a lower priority than the second thread (third threads) in the target run queue will not preempt CPU resources. This prevents the third thread from preempting the first thread's CPU resources, allowing the first thread to execute smoothly and release the read lock as quickly as possible. Furthermore, the second thread can acquire the write lock as quickly as possible, reducing the time the second thread waits for the write lock and improving the second thread's execution efficiency.

[0010] In one possible implementation, the method further includes: a second thread writing information corresponding to the first target thread into a third parameter; the second thread notifying the target processor based on the third parameter to run the first target thread; and the first target thread running on the target processor. It should be noted that because the second thread has not been cleared from the target run queue and is the highest-priority thread in the target run queue, the second thread can be selected by the target processor (also known as the scheduler) as the next thread to run (or to run). Furthermore, because the second thread enters a sleep state and is not actually running, the second thread can notify the target processor to run the first target thread (e.g., the first thread). The second thread can act as a proxy for the first target thread (e.g., the first thread), and the target processor can actually run the first target thread (e.g., the first thread). In other words, the first target thread (e.g., the first thread) can run on the target processor as the second thread. Therefore, when the first thread is running, if there is a thread (e.g., the third thread) with a higher priority than the first thread and lower than the second thread, the third thread will not preempt the first thread's CPU resources. This is because the third thread believes that the CPU is "actually running" the second thread. Since the second thread has a higher priority than the third thread, the third thread will not preempt the CPU resources. This ensures that the first thread runs smoothly and releases the read lock as soon as possible, allowing the second thread to obtain the write lock as soon as possible, reducing the time the second thread waits for the write lock and improving its execution efficiency.

[0011] In one possible implementation, before the second thread reads the first parameter or the second parameter, the method further includes: the first thread writes the first information into the first parameter and the second parameter, and the first information includes the thread identifier of the first thread. In this way, after the second thread reads the first parameter or the second parameter, it can be learned that the thread holding the read lock of the target resource includes the first thread. When the first thread holds the read lock of the target resource, the second thread can enter a sleep state. After the second thread enters a sleep state, the target processor can run the first thread. Moreover, since the second thread is not cleared from the target run queue, the thread (the third thread) with a lower priority than the second thread in the target run queue will not preempt the CPU resources at this time, so that the third thread can be prevented from preempting the CPU resources of the first thread, so that the first thread can be executed smoothly and the read lock can be released as soon as possible. Furthermore, the second thread can hold the write lock as soon as possible, which can reduce the time the second thread waits for the write lock and improve the execution efficiency of the second thread.

[0012] In one possible implementation, after the first thread releases the read lock on the target resource, the method further includes: the first thread updating a first parameter, wherein the first information in the first parameter after the first thread's update is deleted; the first thread determining whether the first parameter after the first thread's update is null; and if the first parameter after the first thread's update is null, the first thread waking up the second thread. It should be noted that if the updated first parameter is null, it indicates that there is currently no thread holding the read-write lock on the target resource (including a read lock thread and a write lock thread). In this case, the second thread can be woken up so that the second thread can hold the write lock and then perform a write operation on the target resource.

[0013] In one possible implementation, the method further includes: if the first parameter after the first thread's update is empty, the first thread clears the second parameter. This prevents other threads from misjudging the thread holding the read-write lock of the target resource, thereby preventing the other threads from impacting their operational efficiency. It is understood that different threads can be the holding threads of the same read-write lock in different time periods. For example, in the first time period, thread A may be the thread that holds the read lock of the target resource the latest, in which case the second parameter includes thread A's information. In the second time period, thread D may be the thread that holds the read lock of the target resource the latest. In this case, if the second parameter still includes thread A's information, threads in the read-write lock waiting queue may be misjudged, mistakenly believing that thread A is the current holding thread of the read-write lock, when in fact, thread D is the holding thread of the read-write lock in the second time period. Therefore, thread A can clear the second parameter, allowing thread D to write its own information into the second parameter, avoiding misjudgment of the next batch of threads waiting for the read-write lock (i.e., threads waiting for the read-write lock in the second time period).

[0014] In a possible implementation, the method further includes: in a case where the first parameter updated by the first thread is not empty and the first thread is the first target thread, the first thread updates the second parameter, the second parameter updated by the first thread being used to indicate a thread holding a read lock of the target resource in the first parameter updated by the first thread for the latest time. The updated second parameter is used to indicate a thread holding a read lock of the target resource in the updated first parameter for the latest time. After the first thread updates the second parameter, the first thread can notify the thread (for example, the second thread) in the waiting queue corresponding to the read-write lock of the updated second parameter, so that the thread (for example, the second thread) in the waiting queue updates the third parameter recorded by the thread (for example, the second thread) itself. The process of notifying the thread (for example, the second thread) in the waiting queue corresponding to the read-write lock of the updated second parameter has overhead. In order to save the overhead as much as possible, the second parameter can be updated again in the case where the first parameter updated by the first thread is not empty and the first thread is the first target thread. In this way, the second parameter does not need to be frequently updated, and unnecessary notification of the thread (for example, the second thread) in the waiting queue of the read-write lock of the updated second parameter (or in other words, unnecessary frequent awakening of the thread in the waiting queue of the read-write lock) can be avoided, and the overhead can be saved.

[0015] In a possible implementation, the method further includes: in a case where the first parameter updated by the first thread is not empty and the first thread is the first target thread, the first thread wakes up the second thread; the second thread reads the first parameter updated by the first thread or the second parameter updated by the first thread, and updates the first target thread in the third parameter to a second target thread, the second target thread being a thread holding a read lock of the target resource in the first parameter updated by the first thread for the latest time. The second target thread is notified by the second thread based on the updated third parameter to run on the target processor; and the second target thread runs on the target processor. In this way, the second thread can act as a proxy of the second target thread (for example, the fourth thread), and the target processor actually runs the second target thread (for example, the fourth thread). That is, the second target thread (for example, the fourth thread) can run on the target processor in the “identity” of the second thread. Therefore, when the fourth thread runs, if there is a thread (for example, the third thread) having a priority higher than that of the fourth thread and lower than that of the second thread, the third thread will not preempt the CPU resource of the fourth thread. This is because the third thread considers that the CPU is actually running the second thread, and since the priority of the second thread is higher than that of the third thread, the third thread will not preempt the CPU resource. In this way, the fourth thread can run smoothly and release the read lock as soon as possible, and then the second thread can hold the write lock as soon as possible, so that the time length for which the second thread waits for the write lock can be reduced, and the execution efficiency of the second thread can be improved.

[0016] In a possible implementation, after the second thread reads the first parameter or the second parameter, the method further includes: the second thread joins the waiting queue; and the first thread waking up the second thread includes: the first thread waking up the second thread based on the waiting queue. In this way, the first thread can accurately wake up the thread (for example, the second thread) that needs to be woken up based on the waiting queue.

[0017] In a possible implementation, the target run queue further includes a fourth thread, the fourth thread holds a read lock of the target resource, and the second thread is woken up in the case that the first thread releases the read lock of the target resource, including: the second thread is woken up in the case that the first thread and the fourth thread both release the read lock of the target resource. In this way, in the case that there are multiple threads (for example, the first thread and the fourth thread) holding the read lock of the target resource, the second thread needs to wait for the write lock and can enter the sleep state. After the second thread enters the sleep state, the target processor can run the first thread and the fourth thread. Moreover, since the second thread is not removed from the target run queue, a thread (the third thread) with a priority lower than that of the second thread in the target run queue does not preempt the CPU resource at this time, so that the third thread can be prevented from preempting the CPU resource of the first thread and the fourth thread, and the first thread and the fourth thread can be executed smoothly and release the read lock as soon as possible. Further, the second thread is woken up and can hold the write lock as soon as possible, so that the time length for the second thread to wait for the write lock can be reduced and the execution efficiency of the second thread can be improved.

[0018] In a possible implementation, the method further includes: the fourth thread writes second information into the first parameter and the second parameter, and the second information includes a thread identifier of the fourth thread. In this way, after the second thread reads the first parameter or the second parameter, the second thread can know that the thread holding the read lock of the target resource includes the fourth thread. In the case that the fourth thread holds the read lock of the target resource, the second thread can enter the sleep state. After the second thread enters the sleep state, the target processor can run the first thread. Moreover, since the second thread is not removed from the target run queue, a thread (the third thread) with a priority lower than that of the second thread in the target run queue does not preempt the CPU resource at this time, so that the third thread can be prevented from preempting the CPU resource of the fourth thread, and the fourth thread can be executed smoothly and release the read lock as soon as possible. Further, the second thread can hold the write lock as soon as possible, so that the time length for the second thread to wait for the write lock can be reduced and the execution efficiency of the second thread can be improved.

[0019] In a possible implementation, after the fourth thread releases the read lock of the target resource, the method further includes: updating, by the fourth thread, the first parameter, and second information in the updated first parameter of the fourth thread is deleted; determining, by the fourth thread, whether the updated first parameter of the fourth thread is empty; and in a case where the updated first parameter of the fourth thread is empty, waking up, by the fourth thread, the second thread. It should be noted that the updated first parameter being empty indicates that there is no thread holding a read-write lock (including a read lock thread and a write lock thread) of the target resource, and in this case, the second thread can be woken up so that the second thread can hold a write lock and perform a write operation on the target resource.

[0020] In a second aspect, a chip system is provided. The chip system includes 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 including 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 including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device can perform the method described in the first aspect and any possible implementation manner thereof.

[0021] In a third aspect, a computer-readable storage medium is provided. The computer-readable storage medium includes computer instructions. When the computer instructions are executed on an electronic device (such as a mobile phone), the electronic device performs the method described in the first aspect and any possible implementation manner thereof.

[0022] In a fourth aspect, a computer program product is provided. When the computer program product is executed on a computer, the computer performs the method described in the first aspect and any possible implementation manner thereof.

[0023] In a fifth aspect, an embodiment of the present application provides a thread processing apparatus. The apparatus includes a processor and a memory coupled to the processor. The memory stores program instructions. When the program instructions stored in the memory are executed by the processor, the apparatus implements the method described in the first aspect and any possible implementation manner thereof. The apparatus can be an electronic device or a server device, or can be a component of the electronic device or the server device, such as a chip.

[0024] In a sixth aspect, an embodiment of the present application provides a thread processing apparatus. The apparatus can be divided into different logical units or modules according to functions. Each unit or module performs different functions to make the apparatus perform the method described in the first aspect and any possible implementation manner thereof.

[0025] It can be understood that the beneficial effects that can be achieved by the chip system described in the second aspect, the computer-readable storage medium described in the third aspect, the computer program product described in the fourth aspect, and the devices described in the fifth and sixth aspects provided above can refer to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a schematic diagram of multi-threaded execution timing based on mutex locks;

[0027] Figure 2 This is a timing diagram of multi-threaded execution based on read-write locks;

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

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

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

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

[0032] Figure 6B A flowchart of another thread processing method provided in an embodiment of the present application;

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

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

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

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

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

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

[0039] 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.

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

[0041] 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.

[0042] 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.

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

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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 may occur during thread execution.

[0048] For example, Figure 1 As shown, it is assumed that a low-priority thread (for example, thread C) in the running state 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 finishes running, 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.

[0049] Similarly, read-write locks 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.

[0050] For example, Figure 2A multi-thread execution schematic diagram based on read-write lock is given. It is assumed that thread C is a thread that holds a read lock first, and thread A is a thread that hopes to hold a write lock. Thread A needs to wait for thread C to release the read lock. The priority of thread A can be high priority, and the priority of thread C can be low priority. During the process in which thread A waits for thread C to release the read lock, thread C can obtain a CPU resource and execute a corresponding task. Ideally, thread C can successfully complete the corresponding task, release the read lock, and wake up thread A, so that thread A can hold the write lock. However, in actual situations, because the priority of thread C is low priority, thread C can be preempted by a medium-priority thread B during the execution of the task. The medium-priority thread B preempts the CPU resource and executes the corresponding task first, causing thread C to be unable to execute the corresponding task for a long time. Thread C needs to wait for thread B to complete the task and release the CPU resource, so as to reacquire the CPU resource to execute the corresponding task. After thread B completes the task, thread B can release the read lock and send a wake-up broadcast. Thread A receives the wake-up broadcast and continues to execute the corresponding task.

[0051] In the process in which thread A waits for thread C to release the read lock, because thread C is preempted by the medium-priority thread B and blocked, the medium-priority thread B executes before the high-priority thread A, that is, the priority inversion problem occurs, causing the high-priority thread to wait for a longer time and reducing the execution efficiency of the high-priority thread.

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

[0053] In the priority ceiling scheme, when a thread accesses a shared resource, the priority of the thread is raised to the highest priority among all threads that can access the resource. The highest priority can be referred to as the priority ceiling of the resource. In the priority ceiling scheme, as long as a thread accesses a shared resource, the priority of the thread is raised, which can cause a low-priority thread to block the running of a high-priority thread.

[0054] The priority inheritance scheme is that when a low-priority thread that occupies a shared resource blocks a high-priority thread, the priority of the thread is dynamically changed. For example, when a thread (for example, thread A) applies for / accesses a shared resource (for example, S), if S is being used by thread C, thread A can compare the priority of thread C with the priority of itself. If the priority of thread C is lower than the priority of itself (that is, thread A), the priority of thread C is raised to the priority of itself. After thread C releases the resource S, the original priority of thread C is restored.

[0055] The priority inheritance scheme and the priority ceiling scheme both need to dynamically change the priority of a thread. Embodiments of the present application provide a processing method of a thread, which can solve the priority inversion problem of a mutex and the priority inversion problem of a read-write lock without changing the priority of the thread, and can reduce the duration of waiting for the read-write lock of a thread (for example, a high-priority thread), thereby improving the execution efficiency of the thread.

[0056] The technical solutions in the embodiments of the present application will be described below. In the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing the specific embodiments and are not intended to be limiting to the present application. As used in the specification and the appended claims of the present application, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that “at least one” and “one or more” as used in the embodiments herein indicates one or two or more (including two). The term “and / or” is used to describe the association relationship of the associated objects, which means that there can be three relationships; for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character “ / ” generally represents an “or” relationship between the associated objects before and after it.

[0057] In this specification, the phrase “one embodiment” or “some embodiments” etc. means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Therefore, the phrases “in one embodiment”, “in some embodiments”, “in other some embodiments”, “in yet some embodiments” etc. appearing in different places in the specification are not necessarily all referring to the same embodiment, but mean “one or more but not all embodiments”, unless otherwise specifically emphasized. The terms “include”, “contain”, “have” and their variants mean “including but not limited to”, unless otherwise specifically emphasized. The term “connection” includes direct connection and indirect connection, unless otherwise specified. “First”, “second” are only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features.

[0058] In the embodiments of the present application, the words “exemplary” or “for example” are used to mean serving as an example, instance, or illustration. Any embodiment or design presented as “exemplary” or “for example” in the embodiments of the present application should not be interpreted as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of “exemplary” or “for example” is intended to present relevant concepts in a concrete manner.

[0059] For ease of understanding, the thread processing method provided in the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0060] For example, Figure 3 As shown in the figure, assume that the current run queue (rq) includes a high-priority thread (e.g., thread X), a medium-priority thread (e.g., thread Y), and a low-priority thread (e.g., thread A). In the original scheduling scheme of the Linux kernel, when a high-priority thread (e.g., thread X) wants to operate a target resource (e.g., a critical section), if it finds that the mutex is already held by a low-priority thread (e.g., thread A), thread X can be removed from the run queue (i.e., cleared from the run queue). At this point, the remaining threads in the run queue include thread Y and thread A. When the CPU performs scheduling, since thread Y has a higher priority than thread A, the CPU will choose thread Y to run, and thread A will be delayed, thereby extending the waiting time of thread X.

[0061] Still taking the current run queue including a high priority thread (e.g., thread X), a medium priority thread (e.g., thread Y), and a low priority thread (e.g., thread A) as an example. Figure 4 As shown, in the thread processing method provided by the embodiment of the present application, when a high-priority thread (for example, thread X) wants to operate a critical section, even if it finds that the mutex lock is already held by a low-priority thread (for example, thread A), thread X will not be removed from the run queue (i.e., cleared from the run queue). In this way, when the CPU is scheduled, thread X with the highest priority will be selected to run. However, thread X needs to wait for thread A to release the mutex lock, so it is only running on the CPU "on the surface". At this time, the CPU can actually run the low-priority thread A. That is, thread X can act as a "proxy" for thread A. During the execution of thread A, the thread that thread Y "sees" running is thread X running on the CPU "on the surface", rather than thread A actually running on the CPU. Since the priority of thread X is higher than the priority of thread Y, thread Y will not preempt the CPU resources of the actually running thread A, thereby ensuring the smooth operation of thread A and reducing the waiting time for thread X.

[0062] The above describes a method for solving the priority inversion problem of mutex locks. However, the above method for solving the priority inversion problem of mutex locks cannot be directly applied to read-write locks to solve the priority inversion problem existing in read-write locks. This is because when the read-write lock is in the read lock state (for example, there is a thread holding the read lock), other threads that want to hold the read lock can also hold the lock, that is, the read-write lock at this time has multiple holding threads. Each time a new thread holds the read lock, the parameters corresponding to the holding thread (for example, owner) can be updated. In other words, the thread recorded in the owner only represents that the thread has held the read lock (a read-write lock in the read lock state), and does not mean that the thread is the thread that actually holds the read lock (the thread may have released the read lock).

[0063] Because the thread (for example, a high-priority thread, such as thread X) does not know which thread actually holds the read lock, thread X will be removed from the run queue. If the thread that actually holds the read lock is a low-priority thread (for example, thread A), since thread X has been removed from the run queue, thread X cannot delegate execution to thread A, causing thread A to be preempted by other threads (for example, medium-priority thread Y) for CPU resources.

[0064] An embodiment of the present application provides a thread processing method that can solve the priority inversion problem of read-write locks.

[0065] The method provided in this application is applicable to various types of read-write locks. For example, these types of read-write locks may include read-write locks in the Linux kernel, read-write locks implemented in the ART virtual machine in the Android system, and read-write locks implemented using other methods. The underlying implementation of these read-write locks may be based on the Linux kernel's futex lock.

[0066] 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:

[0067] 501. The first thread holds a read lock on the target resource.

[0068] In the embodiments of the present application, a thread holding a read lock can be considered to be a thread holding a read-write lock in the read lock state. A first thread holding a read lock on a target resource means that the first thread holds a read-write lock on the target resource, and the read-write lock is in the read lock state. In other words, the first thread is a read lock thread. The first thread can perform read operations on the target resource.

[0069] The target resource may refer to a preset shared resource, such as a variable or a critical section.

[0070] It can be understood that the read-write lock of the target resource can correspond to one or more parameters (also referred to as members or member variables). Exemplarily, the parameters of the read-write lock can include a state flag bit of the read-write lock and a waiting queue of the read-write lock.

[0071] The state flag bit of the read-write lock can be used to indicate the number of threads holding the read-write lock and the type of thread (read lock thread or write lock thread). The state flag bit of the read-write lock can be represented by flag. For example, when the state flag bit of the read-write lock is -1 (i.e., flag = -1), it indicates that the number of threads holding the read-write lock is 1, and the thread holding the read-write lock is a write lock thread. When the state flag bit of the read-write lock is 0 (i.e., flag = 0, or flag == 0), it indicates that the number of threads holding the read-write lock is 0, i.e., no thread holds the read-write lock. When the state flag bit of the read-write lock is 1 (i.e., flag = 1), it indicates that the number of threads holding the read-write lock is 1, and the thread holding the read-write lock is a read lock thread. When the state flag bit of the read-write lock is 2 (i.e., flag = 2), it indicates that the number of threads holding the read-write lock is 2, and the two threads are both read lock threads. That is, when the number of threads holding the read-write lock is greater than 1, multiple threads hold the read-write lock, and the multiple threads are all read lock threads, and the maximum possible number of read lock threads of the read-write lock can be the number of logical CPUs.

[0072] Before the first thread holds the read lock of the target resource, the flag (for example, flag) of the read-write lock can be queried. If the first condition is met, the first thread can hold the read lock.

[0073] Exemplarily, the first condition can be that the flag of the read-write lock is greater than or equal to 0 and less than a preset value. The preset value refers to the maximum number of threads that can hold the read lock simultaneously. Assuming that the preset value is a (a is an integer greater than 1, for example, a = 8), that is, when the flag of the read-write lock is greater than or equal to 0 and less than a (for example, the flag of the read-write lock is 0), it is considered that the first condition is met, and the first thread can hold the read lock (i.e., can perform read operation on the target resource).

[0074] In some embodiments, when the state of the read-write lock is the read lock state, the waiting queue of the read-write lock can include a thread waiting for the write lock, and the thread waiting for the write lock can hold the write lock (i.e., hold the read-write lock, and the read-write lock is in the write lock state) after all read lock threads of the target resource release the read lock (i.e., release the read lock state of the read-write lock). The waiting queue of the read-write lock can be represented by waiter_list.

[0075] In some embodiments, the parameters corresponding to the read-write lock of the target resource may further include a first parameter. The first parameter may be used to indicate at least one thread holding a read lock on the target resource (i.e., holding a read-write lock on the target resource, and the read-write lock is in a read lock state), with the at least one thread being arranged in the order in which the read lock was held. The first parameter may also be referred to as a queue of threads holding the read-write lock (or a read lock thread queue), and may be represented by owner_list.

[0076] In some embodiments, the parameters corresponding to the read-write lock of the target resource may further include a second parameter. The second parameter is used to indicate the thread that holds the read lock the latest among the at least one thread in the owner_list (i.e., the thread that applies for a read operation on the target resource the latest). The second parameter may be represented by owner.

[0077] In some embodiments, when the first thread holds a read lock on the target resource, first information may be written into the first parameter, where the first information includes a thread identifier of the first thread.

[0078] The way the first thread writes the first information into the first parameter is "new addition", that is, the information originally existing in the first parameter remains unchanged. After the first thread writes the first information into the first parameter, the information in the first parameter includes the originally existing information and the first information, that is, the first information is newly added.

[0079] In some embodiments, the first thread may write the first information into the second parameter.

[0080] The way the first thread writes the first information into the second parameter is "replacement", that is, after the first thread writes the first information into the second parameter, the information originally existing in the second parameter is replaced by the first information.

[0081] It is understandable that, since the information in the second parameter can be continuously replaced by later arriving read lock threads, the information in the second parameter can indicate the latest thread that holds the read lock of the target resource (i.e., the latest arriving read lock thread).

[0082] In addition, when the first thread holds the read lock on the target resource, the status flag of the read-write lock can be updated. For example, before the first thread holds the read lock on the target resource, the status flag of the read-write lock can be 0. After the first thread holds the read lock on the target resource, the status flag of the read-write lock can be updated to 1.

[0083] 502. When the first thread holds the read lock of the target resource, the second thread enters a sleep state and is not cleared from the target run queue.

[0084] The second thread is the thread waiting for the write lock and can query the status of the read-write lock of the target resource. If the read-write lock of the target resource is in the read lock state (for example, when the first thread holds the read lock of the target resource), the second thread needs to wait for the read lock thread (for example, the first thread) to release the read lock before it can hold the write lock.

[0085] In some embodiments, the second thread may read the first parameter or the second parameter to determine the first target thread.

[0086] The first target thread may be one of the at least one threads indicated by the first parameter. If the at least one thread is arranged in descending order based on the time at which the read lock on the target resource was held, the first target thread may be the last thread in the at least one thread. If the at least one thread is arranged in descending order based on the time at which the read lock on the target resource was held, the first target thread may be the first thread in the at least one thread. Alternatively, the first target thread may be the thread indicated by the second parameter.

[0087] Furthermore, the second thread may write information corresponding to the first target thread into a third parameter. The third parameter is a parameter used by the second thread to record the thread holding the read-write lock (eg, the read lock thread).

[0088] In some embodiments, the first target thread may be a first thread, and the second thread may write thread information (first information) of the first thread into the third parameter.

[0089] In some embodiments, the second thread may notify the target processor to run the first target thread (eg, the first thread) based on the third parameter. In this way, the first target thread may run on the target processor.

[0090] It should be noted that since the second thread is not removed from the target run queue and the second thread is the highest priority thread in the target run queue, the second thread can be selected by the target processor (which can also be referred to as a scheduler) as the next thread to run (i.e., to be run). Also, since the second thread enters a sleep state and is not actually running, the second thread can notify the target processor to run the first target thread (e.g., the first thread), the second thread can act as a proxy for the first target thread (e.g., the first thread), and the target processor actually runs the first target thread (e.g., the first thread). That is, the first target thread (e.g., the first thread) can be running on the target processor in the "identity" of the second thread. Therefore, when the first thread is running, if there is a thread (e.g., the third thread) with a priority higher than the first thread and lower than the second thread, the third thread will not preempt the CPU resources of the first thread. This is because the third thread believes that the CPU is "actually running" the second thread, and since the priority of the second thread is higher than that of the third thread, the third thread will not preempt the CPU resources. In this way, the first thread can run smoothly and release the read lock as soon as possible, and the second thread can hold the write lock as soon as possible, thereby reducing the time the second thread waits for the write lock and improving the execution efficiency of the second thread.

[0091] The target run queue of the target processor can refer to a run queue running on one CPU core. It can be understood that a processor (e.g., a CPU) can include one or more cores (also referred to as CPU cores), and each CPU core can run a run queue. Each run queue can include a plurality of 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 the thread with a higher priority can have priority to use the CPU (obtain CPU resources).

[0092] In the case where the first thread holds the read lock of the target resource (e.g., in the case where the thread indicated by the first parameter or the second parameter is the first thread), the second thread can enter a sleep state and not be removed from the target run queue.

[0093] In some embodiments, when the read-write lock of the target resource is in a read lock state, the thread waiting for the write lock (e.g., the second thread) can join (hang in) the waiting queue corresponding to the read-write lock of the target resource. When all read locks of the target resource are released (i.e., all read lock threads release the read-write lock in the read lock state), the last thread that releases the read lock (i.e., the last read lock thread that releases the read-write lock (read lock state read-write lock)) can send a wake-up notification to the threads (e.g., the second thread) in the waiting queue of the read-write lock of the target resource to wake up the corresponding threads (e.g., the second thread).

[0094] In some embodiments, the waiting queue corresponding to the read-write lock of the target resource is empty before the second thread reads the first parameter or the second parameter for the first time. The second thread can join (hang in) the waiting queue corresponding to the read-write lock of the target resource when or after reading the first parameter or the second parameter.

[0095] In some embodiments, when the read-write lock of the target resource is in the read lock state (for example, when the first thread holds the read lock), and the waiting queue corresponding to the read-write lock is empty, if a read lock thread arrives (i.e., a new thread (for example, the fifth thread, the sixth thread) applies to hold the read lock), the second parameter can be updated continuously. The information in the second parameter can be replaced by the read lock thread that arrives later, so that the information in the second parameter can indicate the thread (i.e., the read lock thread that arrives latest) that holds the read lock of the target resource for the latest time.

[0096] In some embodiments, when the waiting queue corresponding to the read-write lock of the target resource is not empty, if a read lock thread arrives, the second parameter can not be updated until the thread indicated by the second parameter releases the read lock. This is because, when the waiting queue corresponding to the read-write lock of the target resource is not empty, if the second parameter is updated, the thread (for example, the second thread) in the waiting queue corresponding to the read-write lock needs to be notified of the updated second parameter, so that the thread (for example, the second thread) in the waiting queue updates the third parameter recorded by itself. The process of notifying the thread (for example, the second thread) in the waiting queue corresponding to the read-write lock of the updated second parameter has overhead. In order to save the overhead as much as possible, when the waiting queue corresponding to the read-write lock of the target resource is not empty, if a read lock thread arrives, the second parameter can not be updated until the thread indicated by the second parameter releases the read lock. In this way, the second parameter does not need to be updated frequently, and unnecessary notification (or awakening) of the thread (for example, the second thread) in the waiting queue of the read-write lock to the updated second parameter can be avoided, and the overhead can be saved.

[0097] 503、In the case where the first thread releases the read lock of the target resource, the first thread can wake up the second thread.

[0098] In some embodiments, in the case where the threads holding the read lock of the target resource only include the first thread, the second thread can be woken up after the first thread releases the read lock of the target resource.

[0099] In some embodiments, after the first thread releases the read lock of the target resource, the first thread can update the first parameter, and the first information in the updated first parameter is deleted. Further, the first thread determines whether the updated first parameter is empty. In the case that the updated first parameter is empty, the first thread can wake up the second thread.

[0100] It should be noted that the updated first parameter is empty, which means that there is no thread holding the read-write lock of the target resource (including the read lock thread and the write lock thread), in this case, the second thread can be woken up so that the second thread can hold the write lock and then perform the write operation on the target resource.

[0101] In some embodiments, in the case that the updated first parameter is empty, the first thread can clear the second parameter. In this way, it can avoid the misjudgment of the holding thread of the read-write lock of the target resource by other threads, and avoid affecting the running efficiency of other threads.

[0102] In some embodiments, in the case that the updated first parameter is empty, after the second thread wakes up the thread in the waiting queue of the read-write lock, the waiting queue of the read-write lock can be cleared. In this way, it can avoid the miswaking of the thread in the waiting queue of the read-write lock by the next holding thread of the read-write lock.

[0103] In some embodiments, in the case that the updated first parameter is not empty, if the first thread is the first target thread (the first target thread refers to the thread with the latest time of holding the read lock of the target resource determined by the second thread after the second thread reads the first parameter or the second parameter for the first time), the first thread can update the second parameter. The updated second parameter is used to indicate the thread with the latest time of holding the read lock of the target resource in the updated first parameter. In this way, it can avoid frequent updating of the second parameter, and avoid frequent notification of the updated second parameter to the thread (for example, the second thread) in the waiting queue of the read-write lock (or in other words, avoid frequent waking up of the thread in the waiting queue of the read-write lock), thereby saving the overhead.

[0104] In some embodiments, when the updated first parameter is not empty, if the first thread is the first target thread (the first target thread refers to the thread that holds the read lock of the target resource the latest after the second thread reads the first parameter or the second parameter for the first time), the first thread can wake up the second thread; after the second thread is woken up, it can read the updated first parameter or the updated second parameter, and update the first target thread in the third parameter to the second target thread, where the second target thread is the thread that holds the read lock of the target resource the latest in the updated first parameter (that is, the second target thread is the thread that holds the read lock of the target resource the latest after the second thread is woken up by the first thread and reads (reads) the first parameter or the second parameter for the second time). The second thread can notify the target processor to run the second target thread based on the updated third parameter, so that the second target thread runs on the target processor. In this way, the second thread can act as a proxy for the second target thread (for example, the fourth thread), and the target processor actually runs the second target thread (for example, the fourth thread). That is, the second target thread (for example, the fourth thread) can run on the target processor as the "identity" of the second thread. Therefore, when the fourth thread is running, if there is a thread with a higher priority than the fourth thread and lower priority than the second thread (for example, the third thread), the third thread will not preempt the fourth thread's CPU resources. This is because the third thread believes that the CPU is "actually running" the second thread, and since the second thread's priority is higher than the third thread's, the third thread will not preempt CPU resources. This ensures that the fourth thread runs smoothly and releases the read lock as quickly as possible, allowing the second thread to obtain the write lock as quickly as possible, reducing the time the second thread waits for the write lock and improving the execution efficiency of the second thread.

[0105] 504. The second thread is awakened and holds the write lock of the target resource.

[0106] After being awakened, the second thread can query the status flag of the target resource's read-write lock. If the status flag of the read-write lock indicates that no thread holds the read-write lock, the second thread can hold the write lock of the target resource. For example, if the status flag of the target resource's read-write lock is 0, the second thread can hold the write lock of the target resource and can continue to run.

[0107] In the embodiments of the present application, a thread holding a write lock can be considered to be a thread holding a read-write lock in the write-lock state. A second thread holding a write lock on a target resource means that the second thread holds a read-write lock on the target resource, and the read-write lock is in the write-lock state, that is, the first thread is a write-lock thread. The second thread can perform write operations on the target resource.

[0108] 505. After the second thread finishes running, the target processor schedules the third thread to run.

[0109] The priority of the third thread is lower than the priority of the second thread and higher than the priority of the first thread.

[0110] As described above (the description of step 502), the first target thread (for example, the first thread) can run on the target processor in the "identity" of the second thread. Therefore, when the first thread runs, the third thread considers that the "second thread" is running, and since the priority of the second thread is higher than the priority of the third thread, the third thread will not preempt the CPU resources. In this way, the first thread can run smoothly and release the read lock as soon as possible, so that the second thread can hold the write lock as soon as possible, which can reduce the time length of the second thread waiting for the write lock and improve the execution efficiency of the second thread. After the second thread runs (for example, the first task is completed), the third thread can run. That is, after the first thread and the second thread run, the third thread runs.

[0111] In some embodiments, the third thread is added to the target running queue during the running of the first thread. That is, after the first thread starts running, the third thread is added to the target running queue. In this case, although the priority of the third thread is higher than the priority of the first thread, the third thread will not preempt the CPU resources of the first thread.

[0112] Based on the method provided in the embodiments of the present application, in the case that the first thread holds the read lock of the target resource, the second thread needs to wait for the write lock and can enter the sleep state. After the second thread enters the sleep state, the target processor can run the first thread. Moreover, since the second thread is not removed from the target running queue, at this time, the thread (the third thread) with a priority lower than the second thread in the target running queue will not preempt the CPU resources, so that the third thread can be prevented from preempting the CPU resources of the first thread, so that the first thread can run smoothly and release the read lock as soon as possible, and then the second thread can hold the write lock as soon as possible, which can reduce the time length of the second thread waiting for the write lock and improve the execution efficiency of the second thread.

[0113] In some embodiments, step 502 can be replaced by step 511, and step 511 can further include step 510 before it, and step 503 can be replaced by 512. As shown, it includes: Figure 6A

[0114] 510, the fourth thread holds the read lock of the target resource.

[0115] In some embodiments, the target running queue further includes a fourth thread, and the fourth thread holds the read lock of the target resource.

[0116] After the fourth thread holds the read lock, the second information can be written into the first parameter, and the second information includes the thread identifier of the fourth thread.

[0117] ​In some embodiments, the fourth thread can arrive before the second thread. That is, the fourth thread holds the read lock earlier than the second thread first queries the first parameter or the second parameter. In this way, before the second thread reads the first parameter or the second parameter, the first parameter can include the thread identity of the first thread and the fourth thread, and the second parameter can include the thread identity of the first thread or the fourth thread. If the fourth thread holds the read lock later than the first thread, the second parameter can indicate the fourth thread; if the first thread holds the read lock later than the fourth thread, the second parameter can indicate the first thread. After the second thread reads the first parameter or the second parameter, the first target thread can be determined to be the first thread or the fourth thread, and the first thread or the fourth thread can be written into the third parameter.

[0118] 511、In the case that the first thread and the fourth thread hold the read lock of the target resource, the second thread enters the sleep state and is not removed from the target run queue.

[0119] In some embodiments, after the second thread first queries the first parameter, it is determined that the first thread and the fourth thread hold the read lock of the target resource. In this case, the second thread enters the sleep state and is not removed from the target run queue.

[0120] The remaining description can refer to step 502, which will not be repeated here.

[0121] 512、In the case that the first thread and the fourth thread both release the read lock of the target resource, the first thread or the fourth thread wakes up the second thread.

[0122] In some embodiments, the first thread releases the read lock of the target resource later than the fourth thread releases the read lock of the target resource. In this case, the fourth thread releases the read lock of the target resource first, and can update the first parameter. The second information in the updated first parameter is deleted. Then, the first thread releases the read lock of the target resource. After the first thread releases the read lock of the target resource, the first thread can update the first parameter. The first information in the updated first parameter is deleted. Further, the first thread determines whether the updated first parameter is empty. In the case that the updated first parameter is empty, the first thread can wake up the second thread.

[0123] In some embodiments, the fourth thread releases the read lock on the target resource later than the first thread releases the read lock on the target resource. In this case, the first thread releases the read lock on the target resource first and can update the first parameter, with the first information in the updated first parameter being deleted. Then, the fourth thread releases the read lock on the target resource. After the fourth thread releases the read lock on the target resource, the fourth thread can update the first parameter, with the second information in the updated first parameter being deleted. Further, the fourth thread determines whether the updated first parameter is null. If the updated first parameter is null, the fourth thread can wake up the second thread.

[0124] It should be noted that the updated first parameter is empty, indicating that there is currently no thread holding the read-write lock of the target resource (including the read lock thread and the write lock thread). In this case, the second thread can be awakened so that the second thread can hold the write lock and then perform write operations on the target resource.

[0125] In some embodiments, step 503 may be replaced by step 512, and step 510 may be further included after step 502 and before step 512. Figure 6B Shown, including:

[0126] 510. The fourth thread holds a read lock on the target resource.

[0127] In some embodiments, the target run queue further includes a fourth thread that holds a read lock on the target resource.

[0128] After the fourth thread holds the read lock, the second information may be written into the first parameter, where the second information includes the thread identifier of the fourth thread.

[0129] In some embodiments, the fourth thread may arrive after the second thread. That is, the fourth thread may hold the read lock after the second thread first queries the first or second parameter. Thus, before the second thread first reads the first or second parameter, the first parameter only includes the first thread's thread identifier, and the second parameter includes the first thread's thread identifier. After reading the first or second parameter, the second thread can determine that the first target thread is the first thread and can write the first thread's data into the third parameter. Furthermore, the second thread can also add itself to the wait queue for the read-write lock.

[0130] After the second thread adds itself to the waiting queue of the read-write lock, the fourth thread arrives (the fourth thread can hold the read lock). In this case, the fourth thread can write its own thread information into the first parameter, so that the first parameter can accurately record all read lock threads.

[0131] It should be noted that in the case where the waiting queue of the read-write lock is not empty, the fourth thread can not write the thread information of the fourth thread into the second parameter, that is, the second parameter is not updated. Further, in the case where the thread (for example, the first thread) indicated by the original second parameter releases the read lock, if the fourth thread has not released the read lock, the second parameter can be updated, and the first thread indicated by the second parameter is updated to the fourth thread. In the case where the thread (for example, the first thread) indicated by the original second parameter releases the read lock, if the fourth thread has also released the read lock, the second parameter does not need to be updated. In this way, unnecessary notification (or awakening) of the thread (for example, the second thread) in the waiting queue of the read-write lock about the updated second parameter can be avoided, and thus the overhead can be saved.

[0132] 512、In the case where the first thread and the fourth thread both release the read lock of the target resource, the first thread or the fourth thread awakens the second thread.

[0133] The related description is not repeated here. Figure 6A The related description is not repeated here.

[0134] Based on the method provided in the embodiments of the present application, in the case where multiple threads (for example, the first thread and the fourth thread) hold the read lock of the target resource, the second thread needs to wait for the write lock and can enter the sleep state. After the second thread enters the sleep state, the target processor can run the first thread and the fourth thread respectively. Moreover, since the second thread is not removed from the target running queue, the thread (the third thread) with a lower priority than the second thread in the target running queue cannot preempt the CPU resource, so that the third thread cannot preempt the CPU resource of the first thread and the fourth thread, the first thread and the fourth thread can execute smoothly, and the read lock can be released as soon as possible, and then the second thread can hold the write lock as soon as possible, the time length for the second thread to wait for the write lock can be reduced, and the execution efficiency of the second thread can be improved.

[0135] In some embodiments, the target running queue further includes more threads (for example, a fifth thread, a sixth thread, and the like) holding the read lock of the target resource. The related description of the fifth thread, the sixth thread, and the like can be referred to the related description of the fourth thread and / or the first thread, and is not repeated here.

[0136] As shown in FIG. 8, taken the first thread as thread A and the second thread as thread X as an example, the method for processing the thread provided in the embodiments of the present application is described, and the method includes the following steps. Figure 7

[0137] 701、The thread A checks the flag of the read-write lock.

[0138] ​For example, the parameters corresponding to the read-write lock of the target resource may include flag, owner, waiter_list, and owner_list. For the description of the relevant parameters, please refer to Figure 5 The relevant description of the illustrated embodiment is omitted here for brevity.

[0139] For example, before thread A holds a read lock (that is, a read-write lock in the read lock state), the values ​​of the various parameters of the read-write lock of the target resource can be as follows:

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

[0141] That is, before thread A holds the read lock, the number of threads holding the read-write lock is 0; the thread that reads the lock the latest in owner_list is NULL (i.e. empty), the waiting queue for the read-write lock is empty, and the queue of threads holding the read-write lock is empty.

[0142] 702. When flag satisfies the first condition (for example, flag ≥ 0 and flag < 8), thread A holds the read lock.

[0143] For example, the first condition may be that the flag bit of the read-write lock is greater than or equal to 0 and less than a preset value (e.g., 8). That is, when flag ≥ 0 and flag < 8, thread A can hold the read lock (i.e., can perform a read operation on the target resource).

[0144] After thread A holds the read lock, it can write its own thread information into owner_list and owner.

[0145] For example, after thread A holds the read lock, the values ​​of the parameters of the read-write lock of the target resource can be as follows:

[0146] flag=1, owner=A, waiter_list=empty, owner_list=A;

[0147] That is, after thread A holds the read lock, the number of threads holding the read-write lock is 1; the thread that reads the lock latest in owner_list is thread A, the waiting queue for the read-write lock is empty, and the queue of threads holding the read-write lock includes thread A.

[0148] 703. Thread X checks flag.

[0149] Thread X is the thread that applies for the write lock. Before applying for the write lock, thread X needs to check the flag to determine whether the flag meets the second condition.

[0150] 704a. If flag does not meet the second condition (for example, flag is not 0), thread X enters a sleep state and is not cleared from the target run queue.

[0151] For example, the second condition may be that the flag bit of the read-write lock is 0. That is, when the flag bit of the read-write lock is not 0 (for example, flag = 1), it is considered that the second condition is not met, and thread X is temporarily unable to hold the write lock (that is, cannot perform write operations on the target resource) and waits for other threads holding read locks to release the read locks before it can hold the write lock.

[0152] 704b. Thread X sets X.owner (for example, writes thread information of thread A into X.owner).

[0153] If the flag does not meet the second condition, thread X can set X.owner. For example, if the threads in owner_list are arranged in descending order based on the time they held the read lock on the target resource, the thread information corresponding to the first_owner in owner_list or the thread information corresponding to the owner (for example, the thread information of thread A) can be written to X.owner.

[0154] 704c. Thread X notifies the target processor to run thread A based on X.owner.

[0155] That is, thread X acts as a proxy for thread A, causing the target processor to actually run thread A.

[0156] Thus, because thread X has not been cleared from the target run queue and is the highest-priority thread in the target run queue, thread X can be selected by the target processor (also known as the scheduler) as the next thread to run (or to run). Furthermore, because thread X has entered a sleep state and is not actually running, thread X can notify the target processor to run the first target thread (e.g., thread A). Thread X can act as a proxy for the first target thread (e.g., thread A), and the target processor can actually run the first target thread (e.g., thread A). In other words, the first target thread (e.g., thread A) can run on the target processor as thread X.

[0157] Because the first target thread (for example, thread A) runs on the target processor as thread X, when thread A runs, thread Y thinks it is thread X that is running. Since thread X has a higher priority than thread Y, thread Y will not preempt CPU resources. This ensures that thread A runs smoothly and releases the read lock as quickly as possible, allowing thread X to acquire the write lock as quickly as possible. This reduces the time thread X waits for the write lock and improves thread X's execution efficiency. After thread X completes (for example, after executing the first task), thread Y can run. That is, after threads A and X complete, thread Y runs.

[0158] 705. Thread X joins the waiter_list of the read-write lock.

[0159] If the flag does not meet the second condition, thread X can add itself to the waiter_list of the read-write lock. In this way, when all read locks on the target resource are released, the last thread to release the read lock can send a wakeup notification to the threads in the waiter_list (for example, thread X) to wake up the corresponding threads (for example, thread X).

[0160] For example, after thread X joins the waiter_list of the read-write lock, the values ​​of the parameters of the read-write lock of the target resource can be as follows:

[0161] flag=1, owner=A, waiter_list=X, owner_list=A;

[0162] That is, after thread A holds the read lock, the number of threads holding the read-write lock is 1; the thread that reads the lock the latest in owner_list is thread A, the waiting queue for the read-write lock includes thread X, and the queue of threads holding the read-write lock includes thread A.

[0163] In the embodiment of the present application, steps 704b to 705 may be executed before step 704a, and there is no necessary order of execution between steps 704b and 705. This embodiment does not specifically limit the order of execution between steps 704b and 705.

[0164] 706. Thread A releases the read lock.

[0165] After thread A releases the read lock, it can update the flag, for example, changing the flag value from 1 to 0.

[0166] Optionally, after thread A releases the read lock, it can delete its own information from owner_list.

[0167] Optionally, after thread A deletes its own information from owner_list, if owner_list is empty, thread A can clear owner. This can prevent other threads from misjudging the thread holding the read-write lock of the target resource and affecting the running efficiency of other threads.

[0168] 707. Thread A checks flag, and wakes up thread X if flag meets the second condition (for example, flag is 0).

[0169] After thread A updates the flag, it can determine whether the flag meets the second condition. If the flag meets the second condition, it means that thread A is the last thread to release the read lock, and thread A can wake up thread X based on waiter_list.

[0170] For example, the second condition can be that the flag bit of the read-write lock is 0. When the flag is 0, the second condition is considered to be met. If the flag satisfies the second condition, it means that the number of threads holding the read-write lock is 0, that is, no thread holds the read-write lock. At this time, thread A can wake up thread X so that thread X can promptly hold the write lock.

[0171] After thread A wakes up thread X, it can clear waiter_list. This prevents the next read-write lock holding thread from accidentally waking up a thread that does not need to wait for the read-write lock.

[0172] For example, after thread A wakes up thread X, the values ​​of the parameters of the read-write lock of the target resource may be as follows:

[0173] flag=0, owner=empty, waiter_list=empty, owner_list=empty;

[0174] That is, after thread A holds the read lock, the number of threads holding the read-write lock is 0; the thread that reads the lock the latest in owner_list is empty, the waiting queue of the read-write lock is empty, and the queue of threads holding the read-write lock is empty.

[0175] 708. Thread X checks flag.

[0176] After thread X is awakened, it can check the flag and determine whether the flag meets the second condition.

[0177] 709. When flag satisfies the second condition (for example, flag is 0), thread X holds the write lock.

[0178] In some embodiments, if flag satisfies the second condition, thread X may clear X.owner.

[0179] For example, after thread X holds the write lock, the values ​​of the parameters of the read-write lock of the target resource can be as follows:

[0180] flag=1, owner=X, waiter_list=empty, owner_list=X;

[0181] That is, after thread X holds the write lock, the number of threads holding the read-write lock is 1; the thread that reads the lock latest in owner_list is thread X, the waiting queue for the read-write lock is empty, and the queue of threads holding the read-write lock includes thread X.

[0182] 710. Thread X releases the write lock.

[0183] After thread X completes the corresponding task, it can release the write lock.

[0184] For example, after thread X releases the write lock, the values ​​of the parameters of the read-write lock of the target resource may be as follows:

[0185] flag=0, owner=empty, waiter_list=empty, owner_list=empty;

[0186] That is, after thread X releases the write lock, the number of threads holding the read-write lock is 0; the number of threads holding the read-write lock is empty, the waiting queue of the read-write lock is empty, and the queue of threads holding the read-write lock is empty.

[0187] 711. After thread X releases the write lock, it checks the wait queue (waiter_list) of the read-write lock. If waiter_list is empty, thread X does not need to wake up other threads.

[0188] Based on the method provided in the embodiment of the present application, when thread A holds the read lock of the target resource, thread X can enter the sleep state. After thread X enters the sleep state, the target processor can run thread A. Moreover, since thread X is not cleared from the target run queue, threads with a lower priority than thread X in the target run queue (for example, thread Y) will not preempt CPU resources, which can prevent thread Y from preempting the CPU resources of thread A, allowing thread A to execute smoothly and release the read lock as soon as possible. Furthermore, thread X can hold the write lock as soon as possible, which can reduce the time thread X waits for the write lock and improve the execution efficiency of thread X.

[0189] like Figure 8 As shown, taking the first thread as thread A, the second thread as thread X, and the threads holding the write lock also including a fourth thread (for example, thread B) and a fifth thread (for example, thread C) as an example, the thread processing method provided in the embodiment of the present application is described, and the method includes:

[0190] 801a. Thread A checks the flag of the read-write lock.

[0191] 802a. When flag satisfies the first condition (for example, flag≥0 and flag<8), thread A holds the read lock.

[0192] For steps 801a to 802a, reference may be made to the relevant descriptions of steps 701 to 702, which will not be repeated here.

[0193] 801b. Thread B checks the flag of the read-write lock.

[0194] 802b. When flag satisfies the first condition (for example, flag≥0 and flag<8), thread B holds the read lock.

[0195] For example, after thread B holds the read lock, the values ​​of the parameters of the read-write lock of the target resource can be as follows:

[0196] flag=2, owner=B, waiter_list=empty, owner_list=B->A;

[0197] That is, after thread B acquires the read lock, the number of threads holding the read-write lock is 2; among the threads currently holding the read-write lock, thread B has read the lock the latest. The read-write lock waiting queue is NULL (i.e., empty), and the read-write lock holding thread queue includes thread A and thread B. The threads in owner_list are sorted from latest to earliest based on the time they held the read lock on the target resource, so thread B can be sorted before thread A.

[0198] In addition, the threads in owner_list may also be arranged in order from earliest to latest based on the time sequence of holding the read lock of the target resource. In this case, thread B may be arranged after thread A.

[0199] 801c. Thread C checks the flag of the read-write lock.

[0200] 802c. When flag satisfies the first condition (for example, flag≥0 and flag<8), thread C holds the read lock.

[0201] For example, after thread C holds the read lock, the values ​​of the parameters of the read-write lock of the target resource can be as follows:

[0202] flag=3, owner=C, waiter_list=empty, owner_list=C->B->A;

[0203] That is, after thread C acquires the read lock, the number of threads holding the read-write lock is 3; among the threads currently holding the read-write lock, thread C has the latest read lock acquisition time. The read-write lock waiting queue is NULL (i.e., empty), and the read-write lock holding thread queue includes thread A, thread B, and thread C. Among them, the threads in owner_list are arranged in descending order based on the time of holding the read lock of the target resource. Therefore, thread C can be arranged before thread B, and thread B can be arranged before thread A.

[0204] In addition, the threads in owner_list may also be arranged from earliest to latest based on the time sequence of holding the read lock of the target resource. In this case, thread C may be arranged after thread B, and thread B may be arranged after thread A.

[0205] 803. Thread X checks flag.

[0206] Thread X may arrive after threads A, B, and C hold the read lock and want to hold the write lock. Thread X may first check the flag of the read-write lock to determine whether the flag meets the second condition (for example, the flag is not 0).

[0207] 804a. When flag does not satisfy the second condition (for example, flag is not 0), thread X enters a sleep state and is not cleared from the target run queue.

[0208] 804b. Thread X sets X.owner (for example, writes thread information of thread C into X.owner).

[0209] If the flag does not meet the second condition, thread X can set X.owner. For example, if the threads in owner_list are arranged in descending order based on the time they held the read lock on the target resource, the thread information corresponding to the first_owner in owner_list or the thread information corresponding to the owner (for example, the thread information of thread C) can be written to X.owner.

[0210] 804c. Thread X notifies the target processor to run thread C based on X.owner. That is, thread X acts as a proxy for thread C, so that the target processor actually runs thread C.

[0211] Thus, since thread X is not removed from the target run queue and thread X is the highest priority thread in the target run queue, thread X can be selected by the target processor (may also be referred to as a scheduler) as the next thread to run (i.e., to be run). And since thread X enters the sleep state and is not actually running, thread X can notify the target processor to run the first target thread (e.g., thread C), thread X can act as a proxy for the first target thread (e.g., thread C), and the target processor actually runs the first target thread (e.g., thread C). That is, the first target thread (e.g., thread C) can run on the target processor in the "identity" of thread X.

[0212] Since the first target thread (e.g., thread C) is running on the target processor in the "identity" of thread X. Thus, when thread C runs, thread Y thinks that "thread X" is running, and since the priority of thread X is higher than the priority of thread Y, thread Y will not preempt the CPU resource. In this way, it can be ensured that thread C runs smoothly and releases the read lock as soon as possible, and thus thread X can hold the write lock as soon as possible, which can reduce the length of time that thread X waits for the write lock and improve the execution efficiency of thread X. After thread X runs to completion (e.g., executes the first task), thread Y can run. That is, after thread C and thread X run to completion, thread Y runs.

[0213] 805. Thread X joins the waiter_list of the read-write lock.

[0214] In the embodiments of the present application, steps 804b-805 can be executed before step 804a, and there is no certain execution order between steps 804b-805, and the embodiments do not specifically limit the execution order between steps 804b-805.

[0215] For example, after thread X joins the waiter_list of the read-write lock, the values of the various parameters of the read-write lock of the target resource can be as follows:

[0216] flag = 3, owner = C, waiter_list = X, owner_list = C -> B -> A;

[0217] That is, after thread X joins the waiter_list of the read-write lock, the waiting queue of the read-write lock includes thread X, and the values of the remaining parameters remain unchanged.

[0218] 806a. Thread A releases the read lock.

[0219] After thread A releases the read lock, the flag can be updated. For example, the value of the flag is changed from 3 to 2.

[0220] Optionally, after thread A releases the read lock, thread A can delete its information from the owner_list.

[0221] For example, after thread A releases the read lock, the values of the parameters of the read-write lock of the target resource can be as follows:

[0222] flag = 2, owner = C, waiter_list = X, owner_list = C -> B;

[0223] That is, after thread A releases the read lock, the number of threads holding the read-write lock is 2; the thread with the latest time of the read lock in the owner_list is thread C, the waiting queue of the read-write lock includes thread X, and the holding thread queue of the read-write lock includes thread C and thread B.

[0224] 806b, thread A checks the flag, and if the flag does not satisfy the second condition (for example, the flag is 0), thread X is not awakened.

[0225] 806c, thread B releases the read lock.

[0226] After thread B releases the read lock, the flag can be updated. For example, the value of the flag is changed from 2 to 1.

[0227] Optionally, after thread B releases the read lock, thread B can delete its information from the owner_list.

[0228] For example, after thread B releases the read lock, the values of the parameters of the read-write lock of the target resource can be as follows:

[0229] flag = 1, owner = C, waiter_list = X, owner_list = C;

[0230] That is, after thread B releases the read lock, the number of threads holding the read-write lock is 1; the thread with the latest time of the read lock in the owner_list is thread C, the waiting queue of the read-write lock includes thread X, and the holding thread queue of the read-write lock includes thread C.

[0231] 806d, thread B checks the flag, and if the flag does not satisfy the second condition (for example, the flag is 0), thread X is not awakened.

[0232] 806e, thread C releases the read lock.

[0233] After thread C releases the read lock, the flag can be updated. For example, the value of the flag is changed from 1 to 0.

[0234] Optionally, after thread C releases the read lock, thread C can delete its information from the owner_list.

[0235] For example, after thread C releases the read lock, the values ​​of the parameters of the read-write lock of the target resource may be as follows:

[0236] flag=0, owner=empty, waiter_list=X, owner_list=empty;

[0237] That is, after thread C releases the read lock, the number of threads holding the read-write lock is 0; the thread that reads the lock the latest in owner_list is empty, the waiting queue for the read-write lock includes thread X, and the queue of threads holding the read-write lock is empty.

[0238] 807. Thread C checks flag, and wakes up thread X if flag meets the second condition (for example, flag is 0).

[0239] After thread C updates the flag, it can determine whether the flag meets the second condition. If the flag meets the second condition (for example, the flag is 0), it means that thread C is the last thread to release the read lock, and thread C can wake up thread X based on waiter_list.

[0240] For example, after thread C wakes up thread X, the values ​​of the parameters of the read-write lock of the target resource may be as follows:

[0241] flag=0, owner=empty, waiter_list=empty, owner_list=empty;

[0242] That is, after thread C wakes up thread X, the waiting queue of the read-write lock can be cleared.

[0243] In some embodiments, when the target owner in the owner_list queue finishes holding the lock, if there are one or more owners remaining in the owner_list queue, the owner with the latest read time among the one or more remaining owners can be notified to the thread in the waiter_list (e.g., thread X), so that the thread in the waiter_list (e.g., thread X) can update its own recorded owner (e.g., X.owner). The target owner refers to the thread (e.g., thread C) that holds the latest read lock on the target resource after thread X reads owner_list or owner for the first time. In this way, compared to a solution in which the thread in the waiter_list (e.g., thread X) is notified to update its own recorded owner (e.g., X.owner) each time the owner is updated, the above method can reduce the number of times the threads in the waiter_list are notified of owner updates, thereby reducing overhead.

[0244] 808、Thread X checks the flag.

[0245] After Thread X is woken up, it can check the flag and determine whether the flag satisfies the second condition.

[0246] 809、In the case that the flag satisfies the second condition (e.g., the flag is 0), Thread X holds the write lock.

[0247] Exemplarily, after Thread X holds the write lock, the values of the parameters of the read-write lock of the target resource can be as follows:

[0248] flag = 1, owner = X, waiter_list = empty, owner_list = X;

[0249] That is, after Thread X holds the write lock, the number of threads holding the read-write lock is 1; the thread with the latest time of the read lock in the owner_list is Thread X, the waiting queue of the read-write lock is empty, and the thread queue holding the read-write lock includes Thread X.

[0250] 810、Thread X releases the write lock.

[0251] After Thread X completes the corresponding task, it can release the write lock.

[0252] Exemplarily, after Thread X releases the write lock, the values of the parameters of the read-write lock of the target resource can be as follows:

[0253] flag = 0, owner = empty, waiter_list = empty, owner_list = empty;

[0254] That is, after Thread X releases the write lock, the number of threads holding the read-write lock is 0; the thread holding the read-write lock is empty, the waiting queue of the read-write lock is empty, and the thread queue holding the read-write lock is empty.

[0255] 811、After Thread X releases the write lock, it checks the waiting queue (waiter_list) of the read-write lock. If the waiter_list is empty, Thread X does not need to wake up other threads.

[0256] Based on the method provided in the embodiment of the present application, when there are multiple threads (for example, thread A, thread B and thread C) holding the read lock of the target resource, thread X needs to wait for the write lock and can enter a sleep state. After thread X enters the sleep state, the target processor can run thread A, thread B and thread C respectively. Moreover, since thread X is not cleared from the target run queue, the thread (thread Y) with a lower priority than thread X in the target run queue will not preempt CPU resources, so thread Y can be prevented from preempting the CPU resources of thread A, thread B and thread C, so that thread A, thread B and thread C can be executed smoothly and release the read lock as soon as possible, so that thread X can hold the write lock as soon as possible, which can reduce the time thread X waits for the write lock and improve the execution efficiency of thread X.

[0257] The above embodiment ( Figure 5-Figure 8 The illustrated embodiment is described using the example of a second thread (e.g., thread X) waiting for a write lock. In some embodiments, the first thread can be the write lock thread, and the second thread can be the read lock thread. In this case, if a priority inversion problem occurs, refer to the method for resolving the priority inversion problem of a mutex lock described above, which will not be detailed here.

[0258] 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.

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

[0260] like Figure 9As shown, the electronic device 100 can 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, a headset jack 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0261] The sensor module 180 can include a pressure sensor 180A, a gyro sensor 180B, a barometric 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.

[0262] It can be understood that the structure shown in the embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 can include more or fewer components than shown, or combine certain components, or split certain components, or different component arrangements. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0263] The processor 110 can include one or more processing units, for example: the processor 110 can 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), etc. Different processing units can be independent devices, or can be integrated into one or more processors.

[0264] As an embodiment, the processor 110 can include one or more CPUs. The target processor can be one of these CPUs.

[0265] 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).

[0266] 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.

[0267] 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.

[0268] 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.

[0269] It can be understood that the interface connection relationship between the modules shown in the embodiments is only illustrative and does not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 can also use different interface connection modes or a combination of multiple interface connection modes.

[0270] The charging management module 140 is configured to receive charging input from a charger. The charging management module 140 can charge the battery 142 and also supply power to the electronic device through the power management module 141.

[0271] The power management module 141 is configured 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 to supply power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, and the wireless communication module 160. In other embodiments, the power management module 141 can also be arranged in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be arranged in the same device.

[0272] 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.

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

[0274] The mobile communication module 150 can provide a solution for wireless communication including 2G / 3G / 4G / 5G, etc. applied to the electronic device 100. The mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1 and perform filtering, amplification, etc. on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can also amplify the signals modulated by the modem processor and convert the signals into electromagnetic waves radiated through the antenna 1.

[0275] 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.

[0276] 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.

[0277] 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).

[0278] 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.

[0279] The display screen 194 is configured to display images, videos, and the like. The 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 flex light-emitting diode (FLED), a Miniled, a MicroLed, a Micro-oLed, a quantum dot light emitting diodes (QLED), or the like.

[0280] The electronic device 100 can implement a photographing function through an ISP, the camera 193, a video codec, a GPU, the display screen 194, and an application processor, and the like. The ISP is configured to process data fed back by the camera 193. The camera 193 is configured to capture still images or videos. The digital signal processor is configured to process digital signals, which can be not only digital image signals but also other digital signals. The video codec is configured 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, MPEG 2, MPEG 3, MPEG 4, and the like.

[0281] The camera 193 can include 1 to N. For example, the electronic device can include 2 front cameras and 4 rear cameras. The NPU is a neural-network (NN) computing processor, which is configured to quickly process input information by referring to a biological neural network structure, for example, by referring to a transmission mode between neurons in the human brain, and can also constantly self-learn. Through the NPU, the electronic device 100 can implement intelligent cognition applications, such as image recognition, face recognition, voice recognition, text understanding, and the like.

[0282] 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.

[0283] 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.

[0284] 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.

[0285] The keys 190 include a power key, a volume key, and the like. The keys 190 can be mechanical keys. Alternatively, the keys 190 can be touch keys. The electronic device 100 can receive key input, and generate key signal input related to user settings and function control of the electronic device 100. The motor 191 can generate a vibration prompt. The motor 191 can be used for incoming call vibration prompt, and can be used for touch vibration feedback. The indicator 192 can be an indicator light, and can be used for indicating a charging state, a power change, and can be used for indicating a message, a missed call, a notification, and the like. The SIM card interface 195 is used for connecting a SIM card. The SIM card can be inserted into or pulled out of the SIM card interface 195 to achieve contact and separation with the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support a Nano SIM card, a Micro SIM card, a SIM card, and the like.

[0286] The methods in the above embodiments can be implemented in the electronic device 100 with the hardware structure described above.

[0287] Some embodiments of the present application provide an electronic device, which can include a touch screen, a memory, and one or more processors. The touch screen, the memory, and the processor are coupled. The memory is configured to store computer program code including computer instructions. When the processor executes the computer instructions, the electronic device can perform each function or step performed by the electronic device in the above method embodiments. The structure of the electronic device can refer to the structure of the electronic device 100 shown in Figure 9 .

[0288] The embodiments of the present application also provide a chip system (for example, a system on a chip (SoC)), as shown in Figure 10 , which includes at least one processor 1001 and at least one interface circuit 1002. The processor 1001 and the interface circuit 1002 can be interconnected by a line. For example, the interface circuit 1002 can be used to receive signals from other devices (for example, a memory of the electronic device). For another example, the interface circuit 1002 can be used to send signals to other devices (for example, a touch screen of the electronic device or the processor 1001). Illustratively, the interface circuit 1002 can read instructions stored in the memory, and send the instructions to the processor 1001. When the instructions are executed by the processor 1001, the electronic device can perform each step in the above embodiments. Of course, the chip system can also include other discrete devices, which are not limited in the embodiments of the present application.

[0289] 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 9 The various functions or steps performed by the electronic device 100 shown in FIG.

[0290] 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 9 The various functions or steps performed by the electronic device 100 shown in FIG.

[0291] 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.

[0292] 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.

[0293] 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.

[0294] 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.

[0295] 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.

[0296] 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: In a case where the first thread holds a read lock on a target resource, the second thread enters a sleep state and is not cleared from the target run queue; When the first thread releases the read lock of the target resource, the second thread is awakened and holds the write lock of the target resource; After the second thread finishes running, the third thread runs, and the priority of the third thread is lower than the priority of the second thread and higher than the priority of the first thread.

2. The method according to claim 1, characterized in that Before the second thread enters a sleep state and is not cleared from the target run queue, the method further includes: The second thread reads the first parameter or the second parameter, the first parameter is used to indicate at least one thread holding a read lock of the target resource, the at least one thread is arranged in sequence based on the time sequence of holding the read lock of the target resource, and the at least one thread includes the first thread; the second parameter is used to indicate the first target thread, and the first target thread is the thread that holds the read lock of the target resource the latest among the at least one thread.

3. The method according to claim 2, characterized in that The method further comprises: The second thread writes information corresponding to the first target thread into a third parameter; The second thread notifies the target processor to run the first target thread based on the third parameter; The first target thread runs on the target processor.

4. The method according to claim 2, characterized in that Before the second thread reads the first parameter or the second parameter, the method further includes: The first thread writes first information into the first parameter and the second parameter, where the first information includes a thread identifier of the first thread.

5. The method according to claim 4, characterized in that After the first thread releases the read lock of the target resource, the method further includes: The first thread updates the first parameter, and the first information in the first parameter updated by the first thread is deleted; Determining, by the first thread, whether the first parameter updated by the first thread is empty; When the first parameter updated by the first thread is empty, the first thread wakes up the second thread.

6. The method according to claim 5, characterized in that The method further comprises: When the first parameter updated by the first thread is empty, the first thread clears the second parameter.

7. The method according to claim 5, characterized in that The method further comprises: When the first parameter after being updated by the first thread is not empty and the first thread is the first target thread, the first thread updates the second parameter, and the second parameter after being updated by the first thread is used to indicate the thread that holds the read lock of the target resource the latest in the first parameter after being updated by the first thread.

8. The method according to claim 5 or 7, characterized in that The method further comprises: When the first parameter after being updated by the first thread is not empty and the first thread is the first target thread, the first thread wakes up the second thread; The second thread reads the first parameter updated by the first thread or the second parameter updated by the first thread, and updates the first target thread in the third parameter to a second target thread, where the second target thread is the thread that holds the read lock of the target resource the latest in the first parameter updated by the first thread; The second thread notifies the target processor to run the second target thread based on the updated third parameter; The second target thread runs on the target processor.

9. The method according to any one of claims 5 to 8, characterized in that: After the second thread reads the first parameter or the second parameter, the method further includes: The second thread adds the second thread to a waiting queue; The first thread waking up the second thread includes: The first thread wakes up the second thread based on the waiting queue.

10. The method according to any one of claims 1 to 9, characterized in that The target run queue further includes a fourth thread, the fourth thread holds a read lock of the target resource, and the second thread is awakened when the first thread releases the read lock of the target resource, comprising: When both the first thread and the fourth thread release the read lock of the target resource, the second thread is awakened.

11. The method according to claim 10, characterized in that The method further comprises: The fourth thread writes second information into the first parameter and the second parameter, where the second information includes a thread identifier of the fourth thread.

12. The method according to claim 10 or 11, characterized in that After the fourth thread releases the read lock of the target resource, the method further includes: The fourth thread updates the first parameter, and the second information in the first parameter updated by the fourth thread is deleted; Determining, by the fourth thread, whether the first parameter updated by the fourth thread is empty; In a case where the first parameter after being updated by the fourth thread is empty, the fourth thread wakes up the second thread.

13. 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 12.

14. 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 12.

Images