Reentrant execution method, device and equipment of distributed lock, and readable storage medium
By generating a target lock identifier in the distributed lock and passing it to the second thread, the problem of cross-process lock reentrancy that is difficult to achieve with tools such as Redisson is solved, and a flexible lock reentrancy mechanism and convenient locking processing are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 北京自如信息科技有限公司
- Filing Date
- 2022-09-29
- Publication Date
- 2026-07-28
AI Technical Summary
Existing distributed lock tools such as Redisson struggle to implement lock reentrancy mechanisms for any thread, and the locking process requires cumbersome template code.
By generating a target lock identifier and passing it to the second thread, a cross-process lock reentrancy mechanism is implemented, and locking processing is simplified by using pre-generated locking annotations.
A flexible lock reentrancy mechanism has been implemented, avoiding cumbersome operations in the locking process and improving the convenience and flexibility of locking.
Smart Images
Figure CN115543643B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and specifically to a method, apparatus, device, and readable storage medium for reentrant execution of a distributed lock. Background Technology
[0002] In a distributed environment, there are typically different processes, each containing one or more threads. If threads in multiple processes all need to operate on a certain resource, mutual exclusion will occur, causing interference between the threads. To avoid this, distributed locks are typically used to lock each thread.
[0003] Currently, Redis is a typical example of a distributed lock, and its implementation tool is Redisson. Although Redisson can allocate distributed locks to multiple threads within a process, it requires that the same lock must be acquired repeatedly by the same thread. Due to this thread limitation, it is difficult to implement a lock reentrancy mechanism for any thread. Summary of the Invention
[0004] In view of this, embodiments of the present invention provide a method, apparatus, device, and readable storage medium for reentrant execution of distributed locks, in order to solve the problem of difficulty in implementing a lock reentrancy mechanism for any thread.
[0005] According to a first aspect, embodiments of the present invention provide a method for reentrant execution of a distributed lock, comprising: acquiring a first thread that performs a locking process; when the first thread successfully acquires the lock, generating target locking information corresponding to the first thread, controlling the first thread to execute a target task based on the target locking information, wherein the target locking information includes a target lock identifier; when the target task of the first thread is completed, controlling the first thread to pass the target lock identifier to a second thread; and controlling the second thread to execute a lock reentrancy mechanism based on the target lock identifier.
[0006] The distributed lock reentrancy execution method provided in this embodiment of the invention, after the first thread successfully acquires the lock and the task execution is completed, controls the first thread to pass the target lock identifier to the second thread, so that the second thread can acquire the lock of the first thread according to the target lock identifier and execute the lock reentrancy mechanism. Therefore, for different threads, as long as they can acquire the lock identifier, the corresponding lock reentrancy can be achieved, no longer limited to the same locking thread. That is, any thread can repeatedly acquire the lock as long as it has the corresponding lock identifier, realizing a flexible lock reentrancy mechanism.
[0007] In conjunction with the first aspect, in the first embodiment of the first aspect, controlling the second thread to execute the lock reentry mechanism based on the target lock identifier includes: determining whether the target lock identifier is consistent with the locking identifier of the first thread; when the target lock identifier is consistent with the locking identifier of the first thread, acquiring the target lock corresponding to the first thread; controlling the second thread to execute the lock reentry mechanism based on the target lock, and updating the lock reentry count.
[0008] In conjunction with the first embodiment of the first aspect, in the second embodiment of the first aspect, the method further includes: when the target lock identifier is inconsistent with the locking identifier of the first thread, determining that the second thread has failed to acquire the lock, and generating locking failure information.
[0009] The distributed lock reentrancy execution method provided in this embodiment of the invention compares the target lock identifier of the second thread with the lock identifier of the first thread to determine whether the second thread can successfully acquire the lock. This ensures that the second thread can acquire the lock according to the target lock corresponding to the first thread, realizes a cross-process lock reentrancy mechanism, ensures that different processes can use the same lock, and makes the locking process more flexible.
[0010] In conjunction with the first aspect, in the third embodiment of the first aspect, after controlling the second thread to execute the lock reentrancy mechanism based on the target lock identifier, the method further includes: determining whether there is renewal identifier information for the second thread; when there is no renewal identifier information for the second thread, obtaining renewal identifier information for the second thread; and starting a renewal thread for the second thread based on the renewal identifier information, wherein the renewal thread is used to delay the effective duration of the lock.
[0011] In conjunction with the third implementation of the first aspect, in the fourth implementation of the first aspect, the step of starting the renewal thread of the second thread based on the renewal identifier information includes: obtaining the locking duration of the second thread; determining whether the locking duration has reached a preset time; when the locking duration reaches the preset time, starting the renewal thread based on the renewal identifier information to extend the effective locking duration of the second thread.
[0012] The distributed lock reentrant execution method provided in this embodiment of the invention controls the execution of the renewal thread based on its renewal identifier information and the lock duration when the second thread is in the lock reentrant state, ensuring the smooth execution of the second thread's task and avoiding conflicts with other threads.
[0013] In conjunction with the third embodiment of the first aspect, in the fifth embodiment of the first aspect, the method further includes: obtaining the task execution status of the second thread; releasing the target lock based on the target lock identifier and updating the lock reentry count; when the lock reentry count is updated to 1, releasing the target lock based on the target lock identifier and stopping the renewal thread corresponding to the first thread and / or the second thread.
[0014] The reentrant execution method for distributed locks provided in this embodiment of the invention performs unlocking processing after a thread completes its task execution, stops the renewal thread, and releases the target lock so that other threads can enter, thus ensuring the thread's running effect.
[0015] In conjunction with the first aspect, in the sixth embodiment of the first aspect, obtaining the first thread that performs the locking process includes: in response to an input operation on a locking annotation, performing locking processing on the first thread based on the locking annotation, wherein the locking annotation is annotation information pre-generated based on locking reentrancy processing.
[0016] The reentrant execution method for distributed locks provided in this embodiment of the invention pre-generates locking annotations and performs locking processing on the first thread based on these locking annotations, thereby avoiding the need to input cumbersome locking template code and making locking processing more convenient.
[0017] According to a second aspect, embodiments of the present invention provide a reentrant execution device for a distributed lock, comprising: an acquisition module, configured to acquire a first thread performing a locking process; a generation module, configured to generate target locking information corresponding to the first thread when the first thread successfully acquires the lock, and control the first thread to execute a target task based on the target locking information, the target locking information including a target lock identifier; a first control module, configured to control the first thread to pass the target lock identifier to a second thread after the target task of the first thread has been executed; and a second control module, configured to control the second thread to execute a lock reentrancy mechanism based on the target lock identifier.
[0018] According to a third aspect, embodiments of the present invention provide an electronic device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the reentrant execution method of the distributed lock described in the first aspect or any embodiment of the first aspect.
[0019] According to a fourth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to perform the reentrant execution method of the distributed lock described in the first aspect or any embodiment of the first aspect.
[0020] It should be noted that the beneficial effects of the distributed lock reentrant execution device, electronic device, and computer-readable storage medium provided in the embodiments of the present invention can be found in the description of the corresponding content in the distributed lock reentrant execution method, and will not be repeated here. Attached Figure Description
[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0022] Figure 1 This is a flowchart of a reentrant execution method for a distributed lock according to an embodiment of the present invention;
[0023] Figure 2 This is another flowchart of the reentrant execution method of the distributed lock according to an embodiment of the present invention;
[0024] Figure 3 This is another flowchart of the reentrant execution method of the distributed lock according to an embodiment of the present invention;
[0025] Figure 4 This is a structural block diagram of a reentrant execution device for a distributed lock according to an embodiment of the present invention;
[0026] Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0028] Currently, Redisson is a popular tool for implementing distributed locks, but it has certain drawbacks: 1) Redisson requires the same lock to be acquired repeatedly by the same thread. This limitation makes it difficult to implement repeated locking for any thread, and its lock re-entry mechanism is not flexible enough. 2) Redisson is relatively cumbersome to use, requiring tedious template code for locking. In the code shown below, only the "doSomething()" part is relevant to the business scenario; the rest is template code written for locking.
[0029] RLock lock=redissonClient.getLock("xxxx");
[0030] try{
[0031] lock.lock();
[0032] }catch(IllegalStateException e){
[0033] e.printStackTrace();
[0034] }
[0035] try{
[0036] / / Lock acquired successfully, execute business logic.
[0037] doSomething();
[0038] }finally{
[0039] lock.unlock();
[0040] }
[0041] Based on this, the technical solution of this invention determines the current state of the target thread based on its locking information. When it is in a lock reentrant state, the number of lock reentrant attempts is recorded, and the thread for renewing the lock is controlled according to the task execution state of the target thread. For different threads, as long as they can obtain the locking information, lock reentrantness can be achieved, no longer limited to the same locking thread. That is, any thread can repeatedly acquire the lock as long as it has the locking information. Furthermore, simply adding a locking annotation to the code implementing the task scenario enables automatic locking during task execution. If locking fails, the task is not executed; if locking succeeds, the task is executed, and the lock is automatically released after the task is completed. Compared to existing template code, this is more convenient to use.
[0042] According to an embodiment of the present invention, an embodiment of a reentrant execution method for a distributed lock is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0043] This embodiment provides a reentrant execution method for distributed locks, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 1 This is a flowchart of a reentrant execution method for a distributed lock according to an embodiment of the present invention, as follows: Figure 1 As shown, the process includes the following steps:
[0044] S11, acquire the first thread to execute the locking process.
[0045] The first thread can be any thread within a process. When the first thread needs to access a resource or perform read / write operations on some information, it needs to attempt to lock the resource or information to avoid conflicts with other threads.
[0046] S12, when the first thread successfully acquires the lock, the target lock information corresponding to the first thread is generated, and the first thread is controlled to execute the target task based on the target lock information.
[0047] The target locking information includes the target lock identifier.
[0048] The target lock information is the lock information that the first thread intends to acquire on the resource or read / write information it is trying to access. This target lock information indicates whether the first thread has successfully acquired the lock. Specifically, when the first thread successfully attempts to acquire the lock, it means that the first thread has acquired the lock, and at this time, the electronic device will generate target lock information corresponding to the first thread.
[0049] The target lock identifier is a globally unique identifier for the lock acquired by the first thread, and this target lock identifier can be represented by lockValue. If the target lock acquired by the first thread is lockKey, then there is a one-to-one correspondence between the target lock lockKey and the target lock identifier lockValue, and the target lock lockKey can be mapped based on the target lock identifier lockValue.
[0050] After the first thread acquires the target lock, it can execute its target task. This target task can be implemented using code; it is the code that the first thread needs to execute after successfully acquiring the lock.
[0051] S13, after the target task of the first thread finishes execution, control the first thread to pass the target lock identifier to the second thread.
[0052] The second thread is the thread that needs to be executed after the first thread has finished executing; that is, the first and second threads need to execute consecutively. Normally, after the first thread completes its target task, it can release the lock it has acquired so that other threads can use it.
[0053] Here, to prevent the lock released by the first thread from being preempted by other threads and affecting the continuous execution of the second thread, the first thread does not release the lock after completing the execution of the target task. Instead, it passes the target lock identifier to the second thread, thereby preventing other threads from competing with the second thread for the lock.
[0054] S14, based on the target lock identifier, controls the second thread to execute the lock reentrancy mechanism.
[0055] The lock reentrancy mechanism allows for the repeated acquisition of the same lock. After receiving the target lock identifier from the first thread, the second thread locates the corresponding target lock based on that identifier. At this point, the second thread can acquire the target lock and execute its corresponding task. In other words, the second thread and the first thread have achieved repeated acquisition of the same lock, thus implementing a lock reentrancy mechanism between different processes.
[0056] It should be noted that the above method can also be applied to the reentrancy mechanism of distributed locks for different processes. That is, as long as different processes have the same lock identifier, they can repeatedly acquire the lock, thus realizing the cross-process lock reentrancy mechanism.
[0057] The distributed lock reentrancy execution method provided in this embodiment, after the first thread successfully acquires the lock and the task execution is completed, controls the first thread to pass the target lock identifier to the second thread. This allows the second thread to acquire the lock from the first thread based on the target lock identifier and execute the lock reentrancy mechanism. Therefore, for different threads, as long as they can acquire the lock identifier, they can achieve the corresponding lock reentrancy, no longer limited to the same locking thread. In other words, any thread can repeatedly acquire the lock as long as it possesses the same lock identifier, achieving a flexible lock reentrancy mechanism.
[0058] This embodiment provides a reentrant execution method for distributed locks, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 2 This is a flowchart of a reentrant execution method for a distributed lock according to an embodiment of the present invention, as follows: Figure 2 As shown, the process includes the following steps:
[0059] S21, acquire the first thread to execute the locking process.
[0060] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0061] S22, when the first thread successfully acquires the lock, the target lock information corresponding to the first thread is generated, and the first thread is controlled to execute the target task based on the target lock information.
[0062] The target locking information includes the target lock identifier.
[0063] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0064] S23, after the target task of the first thread finishes execution, control the first thread to pass the target lock identifier to the second thread.
[0065] Specifically, step S23 above may include:
[0066] S231, determine whether the target lock identifier is consistent with the lock identifier of the first thread.
[0067] The lock identifier for the first thread is the identifier that the first thread locks, which is a globally unique identifier that the first thread locks.
[0068] Normally, the target lock identifier passed from the first thread to the second thread is the identifier of the lock it acquires. To further ensure the second thread can execute smoothly, the electronic device can compare the target lock identifier received by the second thread with the lock identifier acquired by the first thread to determine if they match. If the target lock identifier matches the lock identifier acquired by the first thread, step S232 is executed; otherwise, step S234 is executed.
[0069] S232, acquire the target lock corresponding to the first thread.
[0070] When the target lock identifier matches the lock identifier of the first thread, it means that the lock acquired by the first thread matches the target lock identifier, and the second thread can successfully acquire the lock. At this time, the second thread can acquire the target lock corresponding to the target lock identifier, that is, the target lock generated after the first thread successfully acquired the lock.
[0071] S233 controls the second thread to execute the lock reentrancy mechanism based on the target lock and updates the lock reentrancy count.
[0072] After the second thread successfully acquires the lock, it means that the second thread and the first thread can repeatedly acquire the same lock, which is equivalent to the second thread executing the lock reentrancy mechanism. At this time, the electronic device updates the lock reentrancy count of the target lock to determine the number of times the target lock can be repeatedly acquired.
[0073] For example, after the first thread acquires the target lock, its corresponding lock reentry count is 1. When the second thread acquires the target lock again, the corresponding lock reentry count is 2. That is, the process of the second thread acquiring the target lock is equivalent to the reentry process of the target lock.
[0074] S234, determine that the second thread failed to acquire the lock, and generate a lock acquisition failure message.
[0075] When the target lock identifier is inconsistent with the lock identifier of the first thread, it indicates that the second thread has not acquired the lock held by the first thread, and the second thread cannot continue the execution of the first thread. At this time, the electronic device can determine that the second thread failed to acquire the lock and generate a second thread lock acquisition failure message to feed back to the technicians, so that the technicians can perform maintenance and debugging based on the lock acquisition failure message.
[0076] It should be noted that if the first thread fails to pass the target lock identifier to the second thread due to network issues or other malfunctions, the second thread will not have the lock identifier information acquired by the first thread. In this case, the second thread will still fail to acquire the lock, and corresponding lock failure information will be generated.
[0077] S24, based on the target lock identifier, controls the second thread to execute the lock reentrancy mechanism.
[0078] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0079] The distributed lock reentrancy execution method provided in this embodiment compares the target lock identifier of the second thread with the lock identifier of the first thread to determine whether the second thread can successfully acquire the lock. This ensures that the second thread can acquire the lock according to the target lock corresponding to the first thread, realizes a cross-process lock reentrancy mechanism, ensures that different processes can use the same lock, and makes the locking process more flexible.
[0080] This embodiment provides a reentrant execution method for distributed locks, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 3 This is a flowchart of a reentrant execution method for a distributed lock according to an embodiment of the present invention, as follows: Figure 3 As shown, the process includes the following steps:
[0081] S31, acquire the first thread to execute the locking process.
[0082] Specifically, step S31 may include: in response to an input operation on the locking annotation, performing locking processing on the first thread based on the locking annotation.
[0083] Among them, the locking annotation is the annotation information pre-generated based on the locking reentrancy processing.
[0084] Add a locking annotation to the business thread that needs to perform the locking process. This will automatically lock the business thread before it executes. If locking fails, the business thread will not execute. If locking succeeds, the business thread will execute. Once the business thread finishes executing, the lock will be automatically released.
[0085] Specifically, this locking annotation is based on annotation information pre-encapsulated and generated according to the lock reentrancy mechanism of different threads described in the above embodiments, such as the Lock annotation:
[0086] @Lock
[0087] doSomething()
[0088] Before the first thread `doSomething()`, which requires locking, the technician inputs a locking annotation. Accordingly, the electronic device can respond to the technician's input of the locking annotation, generate the locking annotation at the appropriate location based on the input, and lock the first thread `doSomething()` based on the locking annotation when it is executed.
[0089] By pre-generating locking annotations and applying locks to the first thread based on these annotations, the tedious locking template code can be avoided, making locking more convenient.
[0090] S32, when the first thread successfully acquires the lock, the target lock information corresponding to the first thread is generated, and the first thread is controlled to execute the target task based on the target lock information.
[0091] The target locking information includes the target lock identifier.
[0092] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0093] S33, after the target task of the first thread finishes execution, control the first thread to pass the target lock identifier to the second thread.
[0094] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0095] S34 controls the second thread to execute the lock reentrancy mechanism based on the target lock identifier.
[0096] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.
[0097] S35, determine whether there is a renewal identifier for the second thread.
[0098] The renewal identifier is the identifier of the thread executing the renewal. This renewal identifier, along with the target lock and its identifier, can be placed as a single object in the thread-local variable `threadlocal`. Typically, to prevent deadlocks caused by unexpected thread interruption, a validity period is set for the target lock. If renewal is not initiated after the validity period expires, the target lock is automatically released.
[0099] If the second thread's lock duration reaches the target lock's validity period before the task execution ends, the second thread can renew the target lock to continue task execution. When the second thread needs to renew the target lock, the electronic device can check whether there is a renewal flag for the second thread in the thread-local variable `threadlocal`. If no renewal flag is found for the second thread, step S36 is executed; otherwise, a renewal thread is started based on the renewal flag, and the lock reentry count corresponding to the target lock is returned.
[0100] S36, obtain the renewal identifier information for the second thread.
[0101] When there is no renewal identifier for the second thread, the electronic device can allocate the corresponding renewal identifier for the second thread and put the renewal identifier, target lock, and target lock identifier as a whole into the thread-local variable threadlocal for easy direct calling later.
[0102] S37, Start the second thread of renewal based on the renewal identifier information.
[0103] Among them, the renewal thread is used to delay the effective duration of the lock.
[0104] The renewal thread differs from the second thread. As an execution thread independent of the second thread, it only renews the target lock of the second thread when the lock duration of the second thread is about to reach the effective duration and the second thread is still executing the task normally. This delays the effective duration of the target lock and ensures that the second thread can continue to execute the task until the task is completed.
[0105] Specifically, step S37 above may include:
[0106] (1) Get the lock duration of the second thread.
[0107] The lock duration is the duration during which the second thread successfully acquires the lock, and this lock duration is accumulated from the moment the second thread successfully acquires the lock.
[0108] (2) Determine whether the lock duration has reached the preset time.
[0109] The preset time is a pre-defined lock duration, which is shorter than the effective lock duration. This prevents delays in lock renewal from affecting thread performance. For example, if the effective lock duration is 10 seconds, the preset time can be set to 8 seconds.
[0110] After the second thread successfully acquires the lock, the lock duration is compared with a preset time to determine whether the lock duration has reached the preset time. If the lock duration reaches the preset time, step (3) is executed; otherwise, the lock duration is monitored.
[0111] (3) Start the renewal thread based on the renewal identifier information to extend the effective lock duration of the second thread.
[0112] When the lock duration reaches the preset time, it indicates that the second thread is currently executing its task normally, and the task has not yet ended. At this point, the electronic device can call the corresponding renewal thread through the renewal flag information, thereby extending the lock validity period of the second thread.
[0113] It should be noted that if the execution time of the first thread is long during the process of the first thread acquiring the target lock and executing the target task, the first thread can still be allocated the corresponding renewal flag information so that after the first thread executes normally and is about to reach the effective duration of the target lock, the renewal thread can be started to renew the target lock, thus ensuring the running effect of the first thread.
[0114] S38, release the target lock based on the target lock identifier, and update the lock reentry count.
[0115] The electronic device can monitor the task execution progress of the second thread in real time and determine the task execution status of the second thread based on the task execution progress. The task execution status is used to characterize the current state of the second thread executing the task, and the task execution status includes normal execution status, completion status, and interruption status.
[0116] If the second thread's task has not finished, but its execution progress remains unchanged within a certain period of time, then its task execution status can be determined to be in an interrupted state. If the second thread's task has finished executing, then its task execution status can be determined to be in a completed state.
[0117] After the second thread completes its task, the electronic device can stop the renewal thread for the second thread and control the release of the target lock acquired by the second thread itself. Specifically, the second thread can compare its target lock identifier with the locking identifier corresponding to the target lock. If they match, the second thread can unlock its target lock.
[0118] The electronic device releases the target lock it acquired based on the target lock identifier held by the second thread, at which point the lock reentry count is decremented by 1. Simultaneously, the updated lock reentry count is checked to determine if it is indeed 1. Only when the lock reentry count is 1 can releasing the lock truly release the target lock; otherwise, it's merely a single release after multiple reentries, and does not truly release the target lock.
[0119] S39, when the lock reentry count is updated to 1, release the target lock based on the target lock identifier and stop the renewal thread corresponding to the first thread and / or the second thread.
[0120] When the lock reentry count is updated to 1, performing the unlock process again will result in a lock reentry count of 0, meaning the target lock can be truly released. At this point, the electronic device can use the target lock identifier to release the target lock and simultaneously stop the renewal threads corresponding to the first thread and / or the second thread.
[0121] For example, if the lock reentry count is 4, with the second thread having 3 reentry counts and the first thread having 1, after the second thread finishes its task, the electronic device can control it to perform the unlocking process until the lock reentry count reaches 1, indicating that the second thread has completed releasing the target lock. Then, the electronic device controls the first thread to perform the unlocking process, at which point the lock reentry count is updated to 0, indicating that the target lock is truly released for other threads to preempt. If a renewal thread exists, it stops simultaneously with releasing the target lock.
[0122] The distributed lock reentrant execution method provided in this embodiment controls the execution of the renewal thread based on its renewal identifier information and the lock duration when the second thread is in the lock reentrant state. This ensures the smooth execution of the second thread's task and avoids conflicts with other threads. After the thread completes its task execution, an unlocking process is performed, stopping the renewal thread to release the target lock, allowing other threads to enter and ensuring the thread's operational effectiveness.
[0123] This embodiment also provides a reentrant execution device for a distributed lock, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0124] This embodiment provides a reentrant execution device for a distributed lock, such as... Figure 4 As shown, it includes:
[0125] Module 41 is used to obtain the first thread that executes the locking process.
[0126] The generation module 42 is used to generate target locking information corresponding to the first thread when the first thread successfully acquires the lock, and to control the first thread to execute the target task based on the target locking information. The target locking information includes a target lock identifier.
[0127] The first control module 43 is used to control the first thread to pass the target lock identifier to the second thread after the target task of the first thread has been executed.
[0128] The second control module 44 is used to control the second thread to execute the lock reentrancy mechanism based on the target lock identifier.
[0129] Optionally, the first control module 43 may include:
[0130] The judgment submodule is used to determine whether the target lock identifier is consistent with the lock identifier of the first thread.
[0131] The `get` submodule is used to acquire the target lock corresponding to the first thread when the target lock identifier matches the locking identifier of the first thread.
[0132] The update submodule is used to control the second thread to execute the lock reentrancy mechanism based on the target lock and update the lock reentrancy count.
[0133] The determination submodule is used to determine that the second thread failed to acquire the lock when the target lock identifier is inconsistent with the locking identifier of the first thread, and to generate locking failure information.
[0134] Optionally, the acquisition module 41 is specifically used to, in response to an input operation on the locking annotation, perform locking processing on the first thread based on the locking annotation. The locking annotation is annotation information pre-generated based on the locking reentrancy processing.
[0135] Optionally, the reentrant execution device for the aforementioned distributed lock may further include:
[0136] The judgment module is used to determine whether there is a renewal identifier for the second thread.
[0137] The renewal identifier acquisition module is used to acquire renewal identifier information for the second thread when no renewal identifier information for the second thread exists.
[0138] The startup module is used to start a second thread for renewal based on the renewal identifier information. This renewal thread is used to extend the effective duration of the lock.
[0139] The first release module is used to release the target lock based on the target lock identifier and update the lock reentry count.
[0140] The second release module is used to release the target lock based on the target lock identifier and stop the renewal thread corresponding to the first thread and / or the second thread when the lock reentry count is updated to 1.
[0141] Optionally, the aforementioned startup module is specifically used to: obtain the locking duration of the second thread; determine whether the locking duration has reached a preset time; and when the locking duration reaches the preset time, start a renewal thread based on the renewal identifier information to extend the effective locking duration of the second thread.
[0142] In this embodiment, the reentrancy execution device of the distributed lock is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.
[0143] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0144] The distributed lock reentrancy execution device provided in this embodiment, after the first thread successfully acquires the lock and the task execution is completed, controls the first thread to pass the target lock identifier to the second thread. This allows the second thread to acquire the lock from the first thread based on the target lock identifier and execute the lock reentrancy mechanism. Therefore, for different threads, as long as they can acquire the lock identifier, they can achieve the corresponding lock reentrancy, no longer limited to the same locking thread. In other words, any thread can repeatedly acquire the lock as long as it possesses the corresponding lock identifier, realizing a flexible lock reentrancy mechanism.
[0145] This invention also provides an electronic device having the above-described features. Figure 4 The diagram shows a reentrant execution device for a distributed lock.
[0146] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 5 As shown, the electronic device may include: at least one processor 501, such as a central processing unit (CPU), at least one communication interface 503, memory 504, and at least one communication bus 602. The communication bus 602 is used to enable communication between these components. The communication interface 503 may include a display screen or a keyboard; optionally, the communication interface 503 may also include a standard wired interface or a wireless interface. The memory 504 may be high-speed volatile random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 504 may also be at least one storage device located remotely from the aforementioned processor 501. The processor 501 may be combined with... Figure 4 The described apparatus has an application program stored in memory 504, and a processor 501 calls the program code stored in memory 504 to perform any of the above method steps.
[0147] The communication bus 602 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 602 can be divided into an address bus, a data bus, and a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0148] The memory 504 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 504 may also include a combination of the above types of memory.
[0149] The processor 501 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.
[0150] The processor 501 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0151] Optionally, memory 504 is also used to store program instructions. Processor 501 can call the program instructions to implement the functions described in this application. Figures 1 to 3 The reentrant execution method of the distributed lock shown in the embodiment.
[0152] This invention also provides a non-transitory computer storage medium storing computer-executable instructions that can execute the reentrant execution method of the distributed lock in any of the above method embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.
[0153] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A reentrant execution method for a distributed lock, characterized in that, include: Acquire the first thread to execute the locking process; When the first thread successfully acquires the lock, target lock information corresponding to the first thread is generated, and the first thread is controlled to execute the target task based on the target lock information. The target lock information includes a target lock identifier. After the target task of the first thread is completed, control the first thread to pass the target lock identifier to the second thread; The second thread is the thread that needs to be executed after the first thread finishes execution, and the first thread and the second thread execute consecutively; Based on the target lock identifier, the second thread is controlled to execute the lock reentrancy mechanism.
2. The method according to claim 1, characterized in that, The step of controlling the second thread to execute the lock reentrancy mechanism based on the target lock identifier includes: Determine whether the target lock identifier is consistent with the lock identifier of the first thread; When the target lock identifier matches the lock identifier of the first thread, acquire the target lock corresponding to the first thread; Control the second thread to execute the lock reentrancy mechanism based on the target lock and update the lock reentrancy count.
3. The method according to claim 2, characterized in that, Also includes: When the target lock identifier is inconsistent with the lock identifier of the first thread, it is determined that the second thread failed to acquire the lock, and a lock failure message is generated.
4. The method according to claim 1, characterized in that, After controlling the second thread to execute the lock reentrancy mechanism based on the target lock identifier, the method further includes: Determine whether there is a renewal identifier for the second thread; If no renewal identifier information exists for the second thread, obtain the renewal identifier information for the second thread. The second thread's renewal thread is started based on the renewal identifier information. The renewal thread is used to delay the effective duration of the lock.
5. The method according to claim 4, characterized in that, The renewal thread that starts the second thread based on the renewal identifier information includes: Get the lock duration of the second thread; Determine whether the locking duration has reached the preset time; When the lock duration reaches the preset time, the renewal thread is started based on the renewal identifier information to extend the lock validity period of the second thread.
6. The method according to claim 4, characterized in that, Also includes: Release the target lock based on the target lock identifier and update the lock reentry count; When the lock reentry count is updated to 1, the target lock is released based on the target lock identifier and the renewal thread corresponding to the first thread and / or the second thread is stopped.
7. The method according to claim 1, characterized in that, The first thread to acquire the lock acquisition process includes: In response to an input operation on the locking annotation, the first thread is locked based on the locking annotation, wherein the locking annotation is annotation information pre-generated based on the locking reentrancy process.
8. A reentrant execution device for a distributed lock, characterized in that, include: The acquisition module is used to acquire the first thread executing the locking process; The generation module is used to generate target locking information corresponding to the first thread when the first thread successfully acquires the lock, and to control the first thread to execute the target task based on the target locking information. The target locking information includes a target lock identifier. The first control module is used to control the first thread to pass the target lock identifier to the second thread after the target task of the first thread has been executed. The second thread is the thread that needs to be executed after the first thread finishes execution, and the first thread and the second thread execute consecutively; The second control module is used to control the second thread to execute the lock reentrancy mechanism based on the target lock identifier.
9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the reentrant execution method of the distributed lock according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the reentrant execution method of the distributed lock according to any one of claims 1-7.