Read-write lock control method and device, electronic equipment and storage medium

Abstract

This application discloses a read-write lock control method, apparatus, electronic device, and storage medium. The method includes: receiving a write lock request from a first thread, where the first thread is in a lock-waiting state; receiving a read lock request from a second thread, where the second thread is also in a lock-waiting state; if the importance of the second thread is higher than that of the first thread, processing the read lock request to ensure the second thread successfully acquires the read lock. By responding first to read lock requests from threads with higher priority, the throughput of read locks can be improved, effectively reducing thread read lock stalling issues.

Description

Technical Field

[0001] This application belongs to the field of read-write locks, specifically relating to a read-write lock control method, device, electronic device, and storage medium. Background Technology

[0002] When multiple threads share the same resource, simultaneous read operations on the shared resource by multiple threads do not cause thread safety issues. However, if one thread performs a write operation on the shared data, and other threads then attempt to read or write to the shared resource, data safety problems will occur. Therefore, read-write locks were developed. Read-write locks allow multiple threads to acquire the read lock simultaneously, but once one thread acquires the write lock, other threads will enter a waiting queue and wait. Read-write locks are particularly suitable for scenarios where reading occurs most of the time and writing occurs only occasionally, and they are a key technology for maintaining data consistency.

[0003] Currently, the read-write lock in the standard library is an opportunistic lock. Once a thread acquires a read lock, read lock requests from other threads that arrive before the acquired thread releases the read lock will automatically acquire the read lock, forming a read lock queue. The read lock will only be released when all the operations of the threads in the read lock queue have been completed, and only then will a thread that needs to perform a write operation have the opportunity to acquire the write lock.

[0004] In this scenario, the following problem arises: Suppose thread A already holds a read lock, and thread B requests a write lock. If threads continuously request read locks, the threads requesting read locks will have to wait for thread B to successfully write the lock and release the written resources before they can read the lock, which can cause thread read lock stalling. Summary of the Invention

[0005] In view of the above problems, this application proposes a read / write lock control method, device, electronic device, and storage medium to improve the above problems.

[0006] In a first aspect, embodiments of this application provide a read-write lock control method, the method comprising: receiving a write lock holding request sent by a first thread, the first thread being in a lock-waiting state; receiving a read lock holding request sent by a second thread, the second thread being in a lock-waiting state; if the importance of the second thread is higher than that of the first thread, processing the read lock holding request so that the second thread successfully holds the read lock.

[0007] Secondly, embodiments of this application provide a read-write lock control device, the device comprising: a first request receiving unit, configured to receive a write lock holding request sent by a first thread, the first thread being in a lock-equaling state; a second request receiving unit, configured to receive a read lock holding request sent by a second thread, the second thread being in a lock-equaling state; and a processing unit, configured to process the read lock holding request if the importance of the second thread is higher than that of the first thread, so that the second thread successfully holds the read lock.

[0008] Thirdly, embodiments of this application provide an electronic device, including one or more processors and a memory; one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to perform the methods described above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run.

[0010] This application provides a read-write lock control method, apparatus, electronic device, and storage medium. First, a write lock request is received from a first thread, which is in a lock-waiting state. Then, a read lock request is received from a second thread, which is also in a lock-waiting state. If the second thread's priority is higher than the first thread's, the read lock request is processed to ensure the second thread successfully acquires the read lock. By responding to read lock requests from threads with higher priority first, the throughput of read locks can be improved, effectively reducing thread read lock stalling issues. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart of a read-write lock control method according to an embodiment of this application is shown;

[0013] Figure 2 A flowchart of a read-write lock control method according to another embodiment of this application is shown;

[0014] Figure 3 A schematic diagram of the process described in steps S210-S240 is shown in another embodiment of this application;

[0015] Figure 4 A flowchart of a read-write lock control method according to another embodiment of this application is shown;

[0016] Figure 5 A schematic diagram of the process described in steps S310-S360 is shown in another embodiment of this application;

[0017] Figure 6 This illustration shows another schematic diagram of the process described in steps S310-S360 in yet another embodiment of this application;

[0018] Figure 7 A flowchart of a read-write lock control method according to another embodiment of this application is shown;

[0019] Figure 8 This paper shows a structural block diagram of a read / write lock control device according to an embodiment of this application;

[0020] Figure 9 This invention illustrates a structural block diagram of an electronic device for executing a read-write lock control method according to an embodiment of the present invention.

[0021] Figure 10 The present application shows a storage unit for storing or carrying program code that implements the read-write lock control method according to the embodiments of the present application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0023] With the rapid development of mobile terminal technology, consumers' demands for mobile terminals are no longer limited to simple functions, but include the ability to smoothly use multiple functions. As the functional requirements of mobile terminals become increasingly powerful, various ultra-large applications have emerged, which mean ever-increasing demands on system resources. This increased demand for system resources leads to a greater need for the protection and synchronization of shared resources. Current issues observed in the mobile terminal market show that application lag caused by locking / waiting is becoming increasingly severe, and in more serious cases, can even lead to system crashes.

[0024] Operating system locks can generally be divided into two main categories: spin locks and sleep locks.

[0025] Spin locks, on the other hand, involve a thread attempting to acquire a lock. If the lock is already held by another thread, the original thread will loop and continuously check if the lock can be successfully acquired until it exits the loop. This type of lock is typically used in scenarios where shared resource access time is short, or where threads cannot enter a sleep state, such as during an interruption. Sleep locks, on the other hand, involve a thread needing to acquire a lock. If the lock is already held by another thread, the original thread will relinquish the CPU and enter a sleep state until the holding thread releases the lock, at which point it attempts to wake up. The use case for this type of lock is clear: to avoid excessive CPU usage caused by spinning, which leads to high CPU load.

[0026] Among sleep locks, there is a type called read-write lock. Read-write locks are divided into read locks and write locks. During a read operation, multiple threads are allowed to acquire the read lock simultaneously. However, only one thread can acquire the write lock at a time. Other threads that fail to acquire the write lock will enter a sleep state and will be awakened when the write lock is released.

[0027] The inventors discovered in their research on related read-write lock control methods that read-write locks may encounter the following situations during their lifecycle: (1) All threads are reading the lock, so no thread is blocked because the thread holding the read lock will not modify the shared resource, so all threads can access the resource with zero blocking; (2) Reading and writing locks are performed simultaneously, in which case the threads will block each other, regardless of whether the read lock is held first or the write lock is held first.

[0028] Simultaneous read and write lock operations can include several scenarios. One such scenario is write lock -> read lock, where if a thread acquires a write lock first, it needs to modify the resource, while the thread holding the read lock needs to wait for the modification to complete, thus achieving synchronization.

[0029] In another scenario, there is the read lock -> write lock scenario. If a thread holds a read lock first, it must wait for the read lock thread to finish reading before it can modify the resource. Otherwise, the write lock thread may cause the read lock thread to read the resource in a chaotic manner.

[0030] Another scenario involves a read lock -> write lock -> read lock. If thread A already holds a read lock, and thread B acquires a write lock during this period, thread B must wait for thread A to complete reading the resource and release the lock before continuing execution. This is because thread B's write operation must not disrupt the thread currently reading the resource. If thread C acquires a read lock while thread B has acquired a write lock, thread C must wait for thread B to successfully write the lock and release the resource before it can read the lock. This raises a problem: thread A is currently reading the resource and not modifying it, while thread C also holds a read lock. Theoretically, thread C can directly read the resource since there is no conflict between thread A and thread C. Is it necessary for thread C to wait for thread B to acquire the write lock, complete writing, and release the lock before reading the lock? Clearly, this is unnecessary, especially if thread C is a real-time thread or a thread that significantly impacts user experience. Blocking here can lead to user lag or even system crashes.

[0031] Therefore, the inventors have proposed the read-write lock control method, apparatus, electronic device, and storage medium of this application. First, a write lock request is received from a first thread, which is in a lock-waiting state. Then, a read lock request is received from a second thread, which is also in a lock-waiting state. If the importance of the second thread is higher than that of the first thread, the read lock request is processed to ensure the second thread successfully acquires the read lock. By responding to read lock requests from threads with higher priority, the throughput of read locks can be improved, effectively reducing thread read lock stalling issues.

[0032] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0033] Please see Figure 1 This application provides a read-write lock control method, the method comprising:

[0034] Step S110: Receive the write lock request sent by the first thread, and the first thread is in a lock-waiting state.

[0035] In this embodiment, the first thread being in a waiting-for-lock state indicates that the first thread's write lock request has not yet been responded to, and the first thread is waiting for the read-write lock to be released. A write lock is a state of a read-write lock, which includes both write and read lock states. When a thread holds a read-write lock in the write lock state, the thread can perform write operations on the shared resource; when a thread holds a read-write lock in the read lock state, the thread can perform read operations on the shared resource. Write operations are used to write to or modify the shared resource; read operations are used to read from the shared resource. The characteristics of a read-write lock are: multiple threads are allowed to read from the shared resource at the same time; only one thread is allowed to write to the shared resource at the same time; when a write operation is performed, read operations by other threads at the same time are blocked; when a read operation is performed, write operations by all threads at the same time are blocked. For a read lock, because multiple threads are allowed to access the shared resource and perform read operations at the same time, it is called a shared lock; while for a write lock, because only one thread is allowed to access the shared resource and perform write operations at the same time, it is called an exclusive lock.

[0036] Understandably, in scenarios involving read and write operations on shared resources, where write operations are less frequent than read operations, read-write locks can be used to prevent errors in reading shared resources.

[0037] Specifically, when there are no write operations, multiple threads can read shared resources simultaneously without any problem. However, if one thread wants to write to these shared resources, no other thread should be able to read or write to them. To meet the requirement of allowing multiple reads but only one write, a read-write lock can be used.

[0038] As one approach, when a thread needs to write to or modify a shared resource, the thread can send a write lock request to the system. Once the system responds to the write lock request, the thread that sent the request can hold a read-write lock in a write-lock state. In this embodiment, the first thread sending the write lock request can be any type of thread; for example, it can be either a real-time thread or a normal thread. Normal threads can further include system core service threads and regular user threads; regular user threads can include user experience-related threads and general threads; general threads can also include normal threads and debugging threads. Real-time threads can include threads related to web pages and games.

[0039] In this embodiment, one or more first threads can simultaneously send write lock requests to the system. When multiple first threads send write lock requests simultaneously, since the system can only respond to one write lock request from a first thread at a time, as one approach, the system can respond according to the chronological order of the received write lock requests, responding first to the earliest received request and then responding to the subsequent requests in sequence. For example, if the first threads include thread A, thread B, and thread C, and threads A, B, and C simultaneously send write lock requests to the system, with the system receiving thread A's request at 12:05:20, thread B's request at 12:04:59, and thread C's request at 12:05:24, then the system will first respond to thread B's write lock request, then thread A's, and finally thread C's.

[0040] As another approach, different priorities can be pre-set for different types of first threads, allowing the system to respond to write lock requests based on the thread's priority. Specifically, the system first responds to write lock requests from the highest-priority first thread, then to those from lower-priority threads, and finally to the lowest-priority first thread. For example, if the first threads include threads A, B, and C, and all three simultaneously send write lock requests, with threads B and C having higher priorities than thread A, and thread B having a higher priority than thread C, the system will first respond to the write lock request from thread B, then the write lock request from thread C, and finally the write lock request from thread A.

[0041] As another approach, responses can be made based on both the priority of the first thread and the chronological order in which the write lock requests sent by the first thread are received. If multiple write lock requests are received at different times, they are responded to first in chronological order; if multiple write lock requests are received simultaneously, they are responded to according to the priority of the first thread.

[0042] In this embodiment, to enable the system to distinguish between different types of first threads, different thread identifiers can be pre-set for different types of first threads. For the same type of first thread, different sequence numbers can be set according to the thread's priority. For example, the sequence number of the first thread with higher priority can be set to be smaller, and the sequence number of the first thread with lower priority can be set to be larger. Of course, the sequence number of the first thread with higher priority can also be set to be larger, and the sequence number of the first thread with lower priority can be set to be smaller; no specific limitation is made here. Then, after receiving a write lock request sent by a first thread, the system can determine the type and priority of the first thread based on the thread identifier of the first thread that sent the write lock request.

[0043] Step S120: Receive the read lock request sent by the second thread, and the second thread is in a lock-waiting state.

[0044] In this embodiment, the second thread being in a lock-waiting state indicates that the first thread's write lock request has not yet been responded to, and the second thread is waiting for the read-write lock to be released. Since multiple threads can simultaneously request a read lock, the second thread in this embodiment can be one or more. Optionally, the second thread can also be any type of thread; for example, it can be a real-time thread or a normal thread. Normal threads can further include system core service threads and regular user threads; regular user threads can further include user experience-related threads and general threads; and general threads can further include normal threads and debugging threads.

[0045] Step S130: If the importance of the second thread is higher than that of the first thread, process the read lock holding request so that the second thread can successfully hold the read lock.

[0046] In this embodiment, thread importance is used to characterize the degree of importance of a thread to the system. The higher the thread importance, the more important the thread is to the system. Processing a read lock request can be understood as the system responding to the read lock request.

[0047] It is understandable that if the system receives different lock-holding requests from threads of different importance, responding to the lock-holding requests from the less important threads first and making the more important threads wait will have significantly more side effects than the waiting of the less important threads. Therefore, in order to reduce side effects, it is necessary to first determine the importance of the threads, and after determining the importance of the threads, the system should respond to the lock-holding requests from the more important threads first.

[0048] As one approach, if a write lock request is received first from a first thread and a read lock request is received second from a second thread, the priority of responding to the lock request can be determined based on the relative importance of the first and second threads. If the importance of the first thread is greater than or equal to that of the second thread, the system responds to the write lock request sent by the first thread first; if the importance of the first thread is less than that of the second thread, the system responds to the read lock request sent by the second thread first.

[0049] In one approach, the importance of the first and second threads can be determined by their types. In this embodiment, different thread identifiers and corresponding importance are pre-defined for different types of threads. The thread types can include real-time threads, ordinary threads, system core service threads, regular user threads, user experience-related threads, general threads, normal threads, and debugging threads. For example, the thread identifier for a real-time thread can be set to "SSXC", the thread identifier for an ordinary thread to "PTXC", the thread identifier for a system core thread to "XTHXXC", the thread identifier for a regular user thread to "CGYHXC", the thread identifier for a user experience-related thread to "YHTYXGXC", the thread identifier for a general thread to "YBXC", the thread identifier for a normal thread to "ZCXC", and the thread identifier for a debugging thread to "TSXC", etc. If multiple threads are of the same type, a number can be added when setting the corresponding thread identifier, such as setting the thread identifier to "SSXC1, SSXC2, etc."

[0050] Furthermore, the importance of different types of threads can be preset. Since both the first and second threads can be either real-time threads or normal threads, and normal threads can be further divided into system core service threads and regular user threads; regular user threads can be further divided into user experience-related threads and general threads; and general threads can be further divided into normal threads and debugging threads. Therefore, when setting the importance of different types of threads, the importance of real-time threads can be set higher than that of normal threads; the importance of system core service threads can be set higher than that of regular user threads; the importance of user experience-related threads can be set higher than that of general threads; and the importance of normal threads can be set higher than that of debugging threads.

[0051] After the above settings are implemented, when the first thread and the second thread send lock requests to the system, the lock requests can carry corresponding thread identifiers. Therefore, when the system receives the write lock request from the first thread and the read lock request from the second thread, it can first determine the types of the first and second threads based on the thread identifiers carried in the lock requests, and then determine the relative importance of the first and second threads based on their types. For example, if the thread identifier carried in the write lock request of the first thread is "ZCXC" and the thread identifier carried in the read lock request of the second thread is "TSXC", then it can be determined that the first thread is a normal thread and the second thread is a debug thread, thus determining that the first thread is more important than the second thread.

[0052] Alternatively, different importance values ​​can be preset for different types of threads. Upon receiving lock requests from different types of threads, the importance of each thread can be determined based on its importance value, thus determining which thread's lock request the system should respond to first. For example, the importance value of real-time threads can be preset to 80, and the importance value of ordinary threads can be preset to 75. If the first thread is determined to be a real-time thread and the second thread to be an ordinary thread, comparing their respective importance values, 80 is clearly greater than 75. Therefore, the importance of the first thread can be determined to be higher than that of the second thread, and the system can respond to the write lock request sent by the first thread first.

[0053] In this embodiment of the application, optionally, if it is determined through the above two methods that the importance of the second thread is higher than that of the first thread, the control system responds to the second thread's request to hold a read lock, so that the second thread can hold a read-write lock in a read lock state, and thus the second thread can perform read operations on the shared resource.

[0054] This application provides a read-write lock control method that first receives a write lock request from a first thread, then receives a read lock request from a second thread. If the second thread is more important than the first thread, the read lock request is processed to ensure the second thread successfully acquires the read lock. By responding to read lock requests from threads with higher priority, this method improves read lock throughput and effectively reduces thread read lock stalling issues.

[0055] Please see Figure 2 This application provides a read-write lock control method, the method comprising:

[0056] Step S210: If it is detected that a thread has successfully acquired the read lock, receive the write lock acquisition request sent by the first thread.

[0057] Step S220: Receive the read lock request sent by the second thread.

[0058] In this embodiment of the application, the scenario shown in steps S210 and S220 is a read lock -> write lock -> read lock scenario.

[0059] In the above scenario, if the lock acquisition requests are processed in the order they appear, the system should respond to the first thread's write lock request after the thread that successfully acquires the read lock finishes reading the shared resource and releases the lock. This allows the first thread to successfully acquire the write lock. Only after the first thread successfully writes to or modifies the shared resource and releases the lock should the system respond to the second thread's read lock request. However, in this case, the thread that successfully acquires the read lock does not modify the shared resource while reading it. The second thread, also holding a read lock, could theoretically read the shared resource directly. Is it necessary to wait for the first thread to acquire the write lock, complete the write, and release the lock before the second thread can read the resource? Clearly, this is unnecessary, especially if the second thread is a real-time thread or a thread that significantly impacts user experience. Blocking here could lead to a sluggish user experience or even cause a system crash.

[0060] Of course, if the second thread is allowed to directly use the read lock to read the shared resource in this situation, the following two situations may occur: (1) If multiple second threads continuously request to hold the read lock, the first thread will be forced to wait for a longer time, which may cause the first thread to starve to death while waiting for the lock; (2) If the importance of the first thread is higher than that of the second thread, there is no reason to let the first thread wait for the second thread, because the side effects of the first thread waiting are significantly greater than those of the second thread.

[0061] Therefore, to address the aforementioned issues, in this embodiment, when a second thread requests a read lock, the importance of the second thread and the first thread is first determined. Only when the importance of the second thread is higher than that of the first thread can the second thread acquire the lock ahead of the first thread. "Acquiring the lock ahead of the first thread" means that the second thread can bypass the first thread and acquire the corresponding lock first.

[0062] For example, in a scenario where thread A reads the lock, thread B is stuck writing the lock, and thread C is stuck reading the lock, if thread C is allowed to directly read the lock, then thread C might continuously request to read the lock, forcing thread B to wait longer, potentially leading to thread B starving. Furthermore, if thread B is more important than thread C, there's no reason for thread B to wait for thread C, as the side effects of waiting for thread B are significantly greater than those for thread C. Therefore, in this embodiment, when thread C is waiting for a read lock thread to request to hold the lock, the importance relationship between thread C and thread B is first determined. Only when the importance of thread C is higher than that of thread B can thread C acquire the lock, bypassing the priority level.

[0063] Step S230: If the importance of the second thread is higher than that of the first thread, check whether the condition for the first thread to be bypassed is met.

[0064] In this embodiment, the condition for the first thread to be bypassed is a pre-set restriction on the first thread being bypassed. This condition may include that the number of times the first thread is bypassed cannot exceed a certain threshold; and that if the waiting time of the first thread exceeds a certain time threshold, it cannot bypass the restriction again. Both the number threshold and the time threshold can be set to arbitrary values; for example, the number threshold can be set to 5 times, and the time threshold can be set to 100ms. Optionally, to make the set number threshold and time threshold more reasonable, they can be set after multiple trials and analysis of the data from these trials.

[0065] As one approach, after determining that the importance of the second thread is higher than that of the first thread, it is also necessary to determine whether the skipped condition corresponding to the first thread is met. When determining whether the skipped condition for the first thread is met, it can be checked simultaneously whether both conditions in the skipped condition are satisfied. If both are satisfied, then the skipped condition for the first thread is satisfied; otherwise, if either condition is not satisfied, then the skipped condition for the first thread is not satisfied.

[0066] Optionally, when determining whether the skipped condition corresponding to the first thread is met, it is possible to check whether any one of the two conditions in the skipped condition is met. If either of the two conditions in the skipped condition is met, then the skipped condition corresponding to the first thread can also be determined. In this case, if neither of the above two conditions is met, then it can be determined that the skipped condition corresponding to the first thread is not met.

[0067] Step S240: If satisfied, process the read lock holding request so that the second thread can successfully hold the read lock.

[0068] In this embodiment, when the importance of the second thread is higher than that of the first thread, and it is determined that the condition for the first thread to be bypassed is met, the second thread is allowed to acquire the lock by bypassing the first thread. The system responds to the read lock request sent by the second thread so that the second thread can successfully acquire the read lock, and then the second thread can read the shared resource.

[0069] For example, the process described in steps S210-S240 can be as follows: Figure 3As shown, after thread A successfully acquires the lock, if thread B (equivalent to the first thread) requests a write lock, thread B waits for the write lock. Then, thread C (equivalent to the second thread) requests a read lock. At this point, it is first determined whether the importance of thread C is higher than that of thread B. If the importance of thread C is higher than that of thread B, it is then determined whether the overriding condition corresponding to thread B is met. If the overriding condition corresponding to thread B is met, thread C successfully acquires the lock. If the overriding condition corresponding to thread B is not met, thread C waits. If the importance of thread C is not higher than that of thread B, thread C waits.

[0070] This application provides a read-write lock control method. Upon detecting that a thread has successfully acquired a read lock, it receives a write lock acquisition request from a first thread, and then receives a read lock acquisition request from a second thread. If the importance of the second thread is higher than that of the first thread, it checks whether the priority condition for the first thread is met. If so, it processes the read lock acquisition request to allow the second thread to successfully acquire the read lock. By responding to read lock acquisition requests from threads with higher priority first, the throughput of read locks can be improved, effectively reducing the problem of thread read lock stalling.

[0071] Please see Figure 4 This application provides a read-write lock control method, the method comprising:

[0072] Step S310: If it is detected that a thread has successfully acquired the read lock, receive the write lock acquisition request sent by the first thread.

[0073] Step S320: Receive the read lock request sent by the second thread.

[0074] Step S330: If the importance of the second thread is higher than that of the first thread, check whether the condition for the first thread to be bypassed is met.

[0075] Step S340: Obtain the number of times the first thread was bypassed and the waiting time of the first thread.

[0076] As an alternative approach, before step S340, the method may further include: when a write lock request is received from the first thread, if a thread is detected to have successfully acquired a read lock, the count of the first thread being overridden is incremented by one; or, if the second thread is detected to have successfully acquired a read lock, the count of the first thread being overridden is incremented by one.

[0077] Alternatively, before step S340, the process may include: when a write lock request is received from the second thread, if a thread is detected to have successfully acquired a read lock, a timer is started.

[0078] In this embodiment, the number of times the first thread is overridden is the current number of times the first thread has been overridden; similarly, the waiting time of the first thread is the current waiting time of the first thread. A variable can be added to the lock abstract structure to record the number of overridden events, but the timing of the variable update is important. Optionally, the recording of the number of times the first thread is overridden begins when the first thread requests a write lock and finds that it is waiting for a read lock from another thread. At this point, it is already recorded as 1, because the first thread has already waited for a lock, which can be understood as the first thread being overridden once. When the first thread successfully acquires the write lock, the number of times the first thread is overridden is cleared to zero, that is, the overridden variable in the lock structure is cleared to zero.

[0079] In addition, to ensure that the first thread waiting for the write lock does not starve, a timeout monitoring function needs to be added for each write lock. If the first thread waits for the write lock for too long, it will not be allowed to bypass the lock request. The first thread's wait time is recorded starting from the moment it requests the write lock and finds that it is waiting for another thread's read lock. When the first thread successfully acquires the write lock, its wait time is cleared.

[0080] Step S350: If the number of times is less than or equal to a preset number of times and the waiting time is less than or equal to a preset time, it is determined that the condition for the first thread to be bypassed is met, and the read lock holding request is processed so that the second thread can successfully hold the read lock.

[0081] In this embodiment, the preset number of times is a pre-set threshold number of times; the preset duration is a pre-set threshold time.

[0082] If the number of times the first thread is overridden is less than or equal to the preset number, and the current waiting time of the first thread is less than or equal to the preset time, it is determined that the overridden condition of the first thread is met, and the second thread is allowed to override and acquire the lock. The system responds to the write lock request sent by the second thread so that the second thread can successfully acquire the write lock, and then the second thread can read the shared resource.

[0083] Step S360: If the number of times is greater than the preset number of times, or the waiting time is greater than the preset time, it is determined that the condition for the first thread to be bypassed is not met, and the write lock holding request is processed so that the first thread can successfully hold the write lock.

[0084] In this embodiment, if the number of times the first thread is overtaken exceeds a preset number, or the current waiting time of the first thread exceeds a preset time, and it is determined that the overtaking condition for the first thread is not met, then the second thread is not allowed to overtake and acquire the lock. The system responds to the write lock acquisition request sent by the first thread, enabling the first thread to successfully acquire the write lock. Specifically, if the number of times the first thread is overtaken is less than or equal to the preset number, but the current waiting time of the first thread exceeds the preset time, then it is determined that the overtaking condition for the first thread is not met; or, if the number of times the first thread is overtaken is greater than the preset number, but the current waiting time of the first thread is less than or equal to the preset time, then it is determined that the overtaking condition for the first thread is not met.

[0085] For example, the process described in steps S310-S360 can be as follows: Figure 5 As shown, after thread A successfully reads the lock, thread B (equivalent to the first thread) requests a write lock, and then thread C (equivalent to the second thread) requests a read lock. If thread B finds that the lock is being waited for by another thread, its priority count is incremented, and thread B waits. Simultaneously, it checks if thread C's importance is higher than thread B's. If C's importance is higher, it checks if the priority condition for thread B is met. If the condition is met, thread B's priority count is incremented, and thread C successfully acquires the read lock. If C's importance is not higher than B's, or the priority condition for B is not met, thread C waits. After thread A finishes reading the shared resource and releases the lock, the system responds to thread B's write lock request, and thread B successfully acquires the write lock. After thread B successfully acquires the write lock, its priority count is cleared.

[0086] The process described in steps S310-S360 can also be as follows: Figure 6 As shown, Figure 6 exist Figure 5 Based on the existing mechanism, lock waiting time monitoring for thread B has been added. When it is determined that thread B is waiting, the lock waiting start time is recorded; once thread B successfully acquires the write lock, the lock waiting time is cleared.

[0087] This application provides a read-write lock control method. When a thread successfully acquires a read lock, it receives a write lock request from a first thread, and then receives a read lock request from a second thread. If the importance of the second thread is higher than that of the first thread, it checks whether the bypass condition corresponding to the first thread is met. It then obtains the number of times the first thread has been bypassed and its waiting time. If the number of bypasses is less than or equal to a preset number, and the waiting time is less than or equal to a preset time, the bypass condition for the first thread is met, and the read lock request is processed to allow the second thread to acquire the read lock successfully. If the number of bypasses is greater than the preset number, or the waiting time is greater than the preset time, the bypass condition for the first thread is not met, and the write lock request is processed to allow the first thread to acquire the write lock successfully. By using this method, when the importance of the second thread is higher than that of the first thread, and the bypass condition for the first thread is met, the second thread is allowed to acquire the lock, thereby improving read lock throughput and effectively reducing read lock bottlenecks for important system service threads, real-time threads, and user experience-related threads.

[0088] Please see Figure 7 This application provides a read-write lock control method, the method comprising:

[0089] Step S410: If it is detected that a thread has successfully acquired the read lock, receive the write lock acquisition request sent by the first thread.

[0090] Step S420: Receive the read lock request sent by the second thread.

[0091] Step S430: If the importance of the second thread is higher than that of the first thread, process the read lock holding request so that the second thread can successfully hold the read lock.

[0092] Step S440: If the importance of the second thread is lower than or equal to the importance of the first thread, process the write lock holding request so that the first thread can successfully hold the write lock.

[0093] In this embodiment, if the importance of the second thread is lower than or equal to that of the second thread, since the write lock request sent by the first thread precedes the read lock request sent by the second thread, the continuous requests can be responded to according to the order in which the lock requests are sent. Therefore, the system will respond to the read lock request sent by the first thread first. After the first thread successfully acquires the write lock, completes the writing or modification of the shared resource, and releases the lock, the system will then respond to the read lock request sent by the second thread, enabling the second thread to successfully acquire the read lock and thus read the shared resource.

[0094] This application provides a read-write lock control method. Upon detecting that a thread has successfully acquired a read lock, it receives a write lock acquisition request from a first thread, and then receives a read lock acquisition request from a second thread. If the importance of the second thread is higher than that of the first thread, the read lock acquisition request is processed to allow the second thread to acquire the read lock successfully. If the importance of the second thread is lower than or equal to that of the first thread, the write lock acquisition request is processed to allow the first thread to acquire the write lock successfully. By allowing the second thread to acquire the lock beyond its priority level, this method improves read lock throughput and effectively reduces read lock bottlenecks for critical system service threads, real-time threads, and user experience-related threads.

[0095] Please see Figure 8 This application provides a read / write lock control device 500, which includes:

[0096] The first request receiving unit 510 is used to receive a write lock request sent by the first thread, where the first thread is in a lock-waiting state.

[0097] In one manner, the first request receiving unit 510 is specifically used to receive a write lock request sent by the first thread when it is detected that a thread has successfully held a read lock.

[0098] The second request receiving unit 520 is used to receive a read lock request sent by the second thread, which is in a lock-waiting state.

[0099] The processing unit 530 is configured to process the read lock holding request if the importance of the second thread is higher than that of the first thread, so that the second thread can successfully hold the read lock.

[0100] In one approach, the processing unit 530 is specifically used to detect whether the overriding condition corresponding to the first thread is met; if it is met, the read lock holding request is processed so that the second thread can successfully hold the read lock.

[0101] Alternatively, the processing unit 530 is also specifically used to obtain the number of times the first thread has been bypassed and the waiting time of the first thread; if the number of times is less than or equal to a preset number of times and the waiting time is less than or equal to a preset time, it is determined that the bypassing condition corresponding to the first thread is met, and the read lock holding request is processed so that the second thread can successfully hold the read lock.

[0102] Optionally, the processing unit 530 is further configured to, when receiving a write lock request sent by the first thread, increment the count of the first thread being overridden by one if it is detected that a thread has successfully acquired a read lock; or, increment the count of the first thread being overridden by one if it is detected that the second thread has successfully acquired a read lock.

[0103] Optionally, the processing unit 530 is further configured to, if the number of times is greater than the preset number of times, or the waiting time is greater than the preset time, determine that the condition for being bypassed by the first thread is not met, and process the write lock holding request so that the first thread can successfully hold the write lock.

[0104] Optionally, the processing unit 530 is further configured to process the write lock holding request if the importance of the second thread is lower than or equal to the importance of the first thread, so that the first thread can successfully hold the write lock.

[0105] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0106] The following will combine Figure 9 This application describes an electronic device.

[0107] Please see Figure 9 Based on the aforementioned read-write lock control method and apparatus, this application embodiment also provides another electronic device 800 capable of executing the aforementioned read-write lock control method. The electronic device 800 includes one or more (only one shown in the figure) processors 802, a memory 804, and a network module 806 coupled together. The memory 804 stores programs capable of executing the contents of the aforementioned embodiments, and the processor 802 can execute the programs stored in the memory 804.

[0108] The processor 802 may include one or more processing cores. The processor 802 connects to various parts within the electronic device 800 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 804, and by calling data stored in the memory 804. Optionally, the processor 802 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 802 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 802 and may be implemented separately using a communication chip.

[0109] The memory 804 may include random access memory (RAM) or read-only memory (ROM). The memory 804 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 804 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 800 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0110] The network module 806 is used to receive and transmit electromagnetic waves, realizing the mutual conversion between electromagnetic waves and electrical signals, thereby communicating with communication networks or other devices, such as audio playback devices. The network module 806 may include various existing circuit elements for performing these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, user identity modules (SIM cards), memory, etc. The network module 806 can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices through wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks (WLANs), or metropolitan area networks (MANs). For example, the network module 806 can interact with base stations.

[0111] Please refer to Figure 10 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable storage medium 900 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0112] The computer-readable storage medium 900 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 900 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 900 has storage space for program code 910 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 910 may be compressed, for example, in a suitable form.

[0113] This application provides a read-write lock control method, apparatus, electronic device, and storage medium. First, it receives a write lock request from a first thread, which is in a lock-waiting state. Then, it receives a read lock request from a second thread, which is also in a lock-waiting state. If the second thread's priority is higher than the first thread's, the read lock request is processed to ensure the second thread successfully acquires the read lock. By responding to read lock requests from threads with higher priority first, the throughput of read locks can be improved, effectively reducing thread read lock stalling issues.

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

Claims

1. A read-write lock control method, characterized in that, The method includes: Receive a write lock request sent by the first thread, and the first thread is in a lock-waiting state; Receives a read lock request sent by the second thread, and the second thread is in a lock-waiting state; If the importance of the second thread is higher than that of the first thread, check whether the conditions for the first thread to be bypassed are met. The conditions for the first thread to be bypassed include that the number of times the first thread is bypassed is no greater than a preset number, and the waiting time of the first thread is no greater than a preset time. The waiting time is recorded starting from the moment the first thread requests a write lock and it is found that it is waiting for a read lock from another thread. If the conditions are met, the read lock holding request is processed so that the second thread can successfully hold the read lock.

2. The method according to claim 1, characterized in that, If the condition is met, the read lock holding request is processed to enable the second thread to successfully hold the read lock, including: Get the number of times the first thread was bypassed and the waiting time of the first thread; If the number of attempts is less than or equal to a preset number of attempts, and the waiting time is less than or equal to a preset time, it is determined that the condition for the first thread to be bypassed is met, and the read lock holding request is processed so that the second thread can successfully hold the read lock.

3. The method according to claim 2, characterized in that, Before obtaining the number of times the first thread has been bypassed, the process also includes: When a write lock request is received from the first thread, if a read lock is successfully acquired by another thread, the count of the first thread being overridden is incremented by one; or, If the second thread is detected to have successfully acquired the read lock, the count of the first thread being bypassed is incremented by one.

4. The method according to claim 2, characterized in that, The method further includes: If the number of attempts exceeds the preset number of attempts, or the waiting time exceeds the preset time, it is determined that the condition for the first thread to be bypassed is not met, and the write lock request is processed so that the first thread can successfully acquire the write lock.

5. The method according to any one of claims 1-4, characterized in that, The process of receiving the write lock request sent by the first thread includes: If it is detected that a thread has successfully acquired the read lock, the write lock acquisition request sent by the first thread is received.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: If the importance of the second thread is lower than or equal to that of the first thread, the write lock request is processed so that the first thread can successfully acquire the write lock.

7. A read / write lock control device, characterized in that, The device includes: The first request receiving unit is used to receive the write lock request sent by the first thread, where the first thread is in a lock-waiting state. The second request receiving unit is used to receive the read lock request sent by the second thread, which is in a lock-waiting state. The processing unit is configured to, if the importance of the second thread is higher than that of the first thread, detect whether the conditions for the first thread to be bypassed are met. The conditions for being bypassed include that the number of times the first thread has been bypassed is no greater than a preset number, and the waiting time of the first thread is no greater than a preset time. The waiting time is recorded from the moment the first thread requests a write lock and it is found that it is waiting for a read lock from another thread. If the conditions are met, the read lock holding request is processed so that the second thread can successfully hold the read lock.

8. An electronic device, characterized in that, It includes one or more processors; one or more programs are stored in memory and configured to be executed by the one or more processors according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, wherein the program code, when executed by a processor, performs the method according to any one of claims 1-6.

Images