A reentrant lock implementation method and device, electronic equipment and system

Abstract

The application relates to the technical field of computers and discloses an implementation method and device of a reentrant lock, which comprises the following steps: performing a preset identity mapping detection operation on a first task triggering a lock request to obtain a detection result; when the detection result indicates that the first task is a new task, based on a preset double-lock architecture, a preset atomic operation is performed to control the first task to acquire a master lock; when the master lock is successfully acquired, the first task is controlled to acquire an operation lock, and based on the current scene of the first task, the first task performs a resource access control operation through the master lock and a state management operation through the operation lock; and when the master lock is not successfully acquired, the first task is added to a preset waiting queue. It can be seen that the application can provide a new access control mode, which is beneficial to ensuring that a task can safely access a shared resource.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and system for implementing a reentrant lock. Background Technology

[0002] Currently, the HarmonyOS ArkTS platform primarily employs an asynchronous programming model based on Promise and async / await to handle concurrency control.

[0003] In practice, using flags or mutexes to achieve thread synchronization is a common concurrency control method. For example, global variables can be used in conjunction with conditional statements, or the basic synchronization primitives provided by the system can be relied upon.

[0004] However, in practice, it has been found that traditional concurrency control methods, when dealing with complex concurrency scenarios, often use polling mechanisms to check resource status or simple queue management to wait for tasks. That is, in the HarmonyOS taskpool environment, existing technologies mainly rely on the built-in mechanism of the task scheduler to handle resource contention, which can easily lead to insecurity when tasks access shared resources. Therefore, proposing a new access control method to ensure that tasks can safely access shared resources is particularly important. Summary of the Invention This invention provides a method and apparatus for implementing a reentrant lock, which can provide a new access control method and help ensure that tasks can securely access shared resources.

[0005] To address the aforementioned technical problems, the first aspect of this invention discloses a method for implementing a reentrant lock. This method is applied to an electronic device with an application installed, and the electronic device is communicatively connected to a network-attached storage device (NATD), accessing the NATD through the application. The method is used to control shared resources in the electronic device or the NATD; wherein the method includes: A preset identity mapping detection operation is performed on the first task that triggers the lock request to obtain the detection result. The identity mapping detection operation includes the operation of detecting the first task through a preset task identity mapping table. When the detection result indicates that the first task is a new task, based on the preset dual-lock architecture, the first task is controlled to acquire the master lock by executing a preset atomic operation. The dual-lock architecture consists of the master lock and the operation lock. The master lock is used to instruct the first task to perform the resource access control operation, and the operation lock is used to instruct the first task to perform the state management operation. When the first task successfully acquires the master lock, it is controlled to acquire the operation lock. Based on the current scenario of the first task, the first task performs resource access control operations through the master lock and performs state management operations through the operation lock. When the first task fails to acquire the master lock, the first task is added to a preset waiting queue. The waiting queue is either empty or includes at least one waiting task, which is a task waiting to request a lock. The waiting queue is used to indicate a wake-up operation for any of the waiting tasks.

[0006] As an optional implementation, in the first aspect of the present invention, when the waiting queue includes at least one of the waiting tasks, the waiting queue also includes the waiting time for each of the waiting tasks; Furthermore, the first task is awakened in the waiting queue in the following manner: Based on the waiting time of all the waiting tasks, the task wake-up order corresponding to the waiting queue is determined, and the task wake-up order is used to indicate the wake-up order of each of the waiting tasks in the waiting queue. When the master lock is released, a preset task wake-up function is called to wake up the currently waiting task in the current wake-up order indicated by the task wake-up order, so as to trigger the currently waiting task to acquire the master lock. When the currently waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all the waiting tasks is re-executed until the currently waiting task is the first task. When the currently waiting task is the first task and the master lock is released, the first task is awakened.

[0007] As an optional implementation, in the first aspect of the present invention, the method further includes: Based on a preset timed detection mechanism, the status information of the master lock is detected once at preset intervals. The status information of the master lock is used to indicate the occupancy status of the master lock, which includes an occupied status or an unoccupied status. Based on the waiting time of all the waiting tasks in the waiting queue, timeout tasks are identified in the waiting queue to obtain an identification result; and when the identification result indicates that there are timeout tasks in the waiting queue, the waiting tasks identified as timeout tasks are removed from the waiting queue to obtain a new waiting queue. Based on the status information of the master lock, determine whether the current condition of the master lock meets the preset deadlock condition; When it is determined that the current condition of the master lock meets the deadlock condition, the master lock is forcibly released, and for the new waiting queue, the preset task wake-up function is triggered to wake up the operation of the currently waiting task in the current wake-up order indicated by the task wake-up order.

[0008] As an optional implementation, in the first aspect of the present invention, determining whether the current condition of the master lock satisfies a preset deadlock condition based on the master lock's state information includes: Based on the status information of the master lock, detect the occupancy status of the master lock; When it is detected that the master lock is in the unoccupied state, it is determined that the current condition of the master lock does not meet the preset deadlock condition; When the master lock is detected to be in the occupied state, the task identity mapping table is checked; and when the task identity mapping table is detected to be empty, it is determined that the current condition of the master lock meets the preset deadlock condition.

[0009] As an optional implementation, in the first aspect of the present invention, the task identity mapping table is used to record the correspondence between the task identifier and the number of reentries of the lock it holds; And, the first task that triggers the request lock performs a preset identity mapping detection operation to obtain the detection result, including: Obtain the first task identifier of the first task that triggered the lock request; and verify the validity of the first task identifier; When the verification is successful, the first task is queried through the task identity mapping table based on the first task identifier; When the first task is found to exist in the task identity mapping table, the reentry count value of the first task is incremented by 1, and the detection result is determined to be that the first task is not a new task. When it is found that the first task does not exist in the task identity mapping table, the first task is identified as a new task and used as the detection result.

[0010] As an optional implementation, in the first aspect of the present invention, the method further includes: Based on the obtained second task identifier, check whether the second task exists in the task identity mapping table; the second task is the task that triggers the lock release. If the second task is detected to exist in the task identity mapping table, the reentry count value of the second task is decremented by 1 to determine whether the reentry count value of the second task is less than or equal to zero. When it is determined that the reentrancy count value of the second task is less than or equal to zero, the second task performs the lock release operation.

[0011] A second aspect of the present invention discloses an apparatus for implementing a reentrant lock, the apparatus being applied to an electronic device with an application installed, the electronic device being communicatively connected to a network-attached storage device and accessing the network-attached storage device through the application, the apparatus being used to control shared resources in the electronic device or the network-attached storage device; wherein, the apparatus includes: The detection module is used to perform a preset identity mapping detection operation on the first task that triggers the request lock and obtain the detection result. The identity mapping detection operation includes the operation of detecting the first task through a preset task identity mapping table. The acquisition module is used to control the first task to acquire the master lock by executing a preset atomic operation based on a preset dual-lock architecture when the detection result indicates that the first task is a new task. The dual-lock architecture consists of the master lock and the operation lock. The master lock is used to instruct the first task to execute the resource access control operation, and the operation lock is used to instruct the first task to execute the state management operation. The control module is used to control the first task to acquire the operation lock when the first task successfully acquires the master lock, and to have the first task perform resource access control operations through the master lock and state management operations through the operation lock based on the current scenario of the first task. The wake-up module is used to add the first task to a preset waiting queue when the first task fails to acquire the master lock. The waiting queue is either empty or includes at least one waiting task, which is a task waiting to request the lock. The waiting queue is used to indicate the wake-up operation for any of the waiting tasks.

[0012] As an optional implementation, in a second aspect of the invention, when the waiting queue includes at least one of the waiting tasks, the waiting queue also includes the waiting duration for each of the waiting tasks; Furthermore, the first task is awakened in the waiting queue in the following manner: Based on the waiting time of all the waiting tasks, the task wake-up order corresponding to the waiting queue is determined, and the task wake-up order is used to indicate the wake-up order of each of the waiting tasks in the waiting queue. When the master lock is released, a preset task wake-up function is called to wake up the currently waiting task in the current wake-up order indicated by the task wake-up order, so as to trigger the currently waiting task to acquire the master lock. When the currently waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all the waiting tasks is re-executed until the currently waiting task is the first task. When the currently waiting task is the first task and the master lock is released, the first task is awakened.

[0013] As an optional implementation, in the second aspect of the present invention, the detection module is further configured to detect the status information of the master lock once at a preset time interval based on a preset time detection mechanism. The status information of the master lock is used to indicate the occupancy status of the master lock, and the occupancy status includes an occupied status or an unoccupied status. The device also includes: The identification processing module is used to identify timed-out tasks in the waiting queue based on the waiting time of all the waiting tasks in the waiting queue, and obtain an identification result; and when the identification result indicates that there are timed-out tasks in the waiting queue, the waiting tasks identified as timed-out tasks are removed from the waiting queue, and a new waiting queue is obtained. The deadlock detection module is used to determine whether the current condition of the master lock meets the preset deadlock condition based on the state information of the master lock. The forced release module is used to forcibly release the main lock when the deadlock judgment module determines that the current condition of the main lock meets the deadlock condition, and to trigger the execution of the preset task wake-up function for the new waiting queue, so as to wake up the operation of the currently waiting task in the current wake-up order indicated by the task wake-up order.

[0014] As an optional implementation, in a second aspect of the present invention, the specific method by which the deadlock determination module determines whether the current condition of the master lock meets the preset deadlock condition based on the state information of the master lock includes: Based on the status information of the master lock, detect the occupancy status of the master lock; When it is detected that the master lock is in the unoccupied state, it is determined that the current condition of the master lock does not meet the preset deadlock condition; When the master lock is detected to be in the occupied state, the task identity mapping table is checked; and when the task identity mapping table is detected to be empty, it is determined that the current condition of the master lock meets the preset deadlock condition.

[0015] As an optional implementation, in a second aspect of the present invention, the task identity mapping table is used to record the correspondence between a task identifier and the number of re-entries of the lock it holds; Furthermore, the detection module performs a preset identity mapping detection operation on the first task that triggers the request lock, and the specific methods for obtaining the detection results include: Obtain the first task identifier of the first task that triggered the lock request; and verify the validity of the first task identifier; When the verification is successful, the first task is queried through the task identity mapping table based on the first task identifier; When the first task is found to exist in the task identity mapping table, the reentry count value of the first task is incremented by 1, and the detection result is determined to be that the first task is not a new task. When it is found that the first task does not exist in the task identity mapping table, the first task is identified as a new task and used as the detection result.

[0016] As an optional implementation, in a second aspect of the present invention, the detection module is further configured to detect whether the second task exists in the task identity mapping table based on the second task identifier of the acquired second task, wherein the second task is the task that triggers the release lock; The device also includes: The reentry determination module is used to determine whether the reentry count value of the second task is less than or equal to zero by decrementing the obtained reentry count value of the second task by 1 if the second task is detected to exist in the task identity mapping table. The normal release module is used to allow the second task to release the lock when the reentry determination module determines that the reentry count value of the second task is less than or equal to zero.

[0017] A third aspect of the present invention discloses another means of implementing a reentrant lock, the means comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the reentrant lock implementation method disclosed in the first aspect of the present invention.

[0018] A fourth aspect of the present invention discloses a system for implementing a reentrant lock. The system includes at least a reentrant lock implementation apparatus as described in the second aspect of the present invention, and a network-attached storage device communicatively connected to the reentrant lock implementation apparatus. The network-attached storage device stores shared resources. When the reentrant lock implementation apparatus triggers a target task that processes the shared resources, the reentrant lock implementation apparatus performs a control operation on the shared resources based on the reentrant lock implementation method as described in any of the first aspects of the present invention and on the shared resources; or... The system includes at least an electronic device as described in the third aspect of the present invention, and a network-attached storage device communicatively connected to the electronic device, wherein the network-attached storage device stores shared resources. When the electronic device triggers a target task to process the shared resources, the electronic device performs a control operation on the shared resources based on the shared resources and in accordance with the reentrant lock implementation method as described in any of the first aspects of the present invention.

[0019] The fifth aspect of the present invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute the reentrant lock implementation method disclosed in the first aspect of the present invention.

[0020] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: Implementing this invention provides a new access control method. Based on a dual-lock mechanism of atomic operations and task identity mapping, it enables tasks requesting locks to control access to shared resources. This helps ensure that tasks requesting locks can safely access shared resources, thereby improving the accuracy and efficiency of resource access control and ultimately enhancing thread safety in a multi-tasking environment. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a method for implementing a reentrant lock according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating another method for implementing a reentrant lock as disclosed in an embodiment of the present invention. Figure 3 This is a flowchart illustrating another method for implementing a reentrant lock as disclosed in an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of a reentrant lock implementation device disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of another reentrant lock implementation device disclosed in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a reentrant lock implementation system disclosed in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a reentrant lock implementation system disclosed in an embodiment of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and 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.

[0024] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] This invention discloses a method and apparatus for implementing a reentrant lock, providing a novel access control approach. Based on a dual-lock mechanism of atomic operations and task identity mapping, it controls the access of tasks requesting locks to shared resources. This ensures that tasks requesting locks can safely access shared resources, thereby improving the accuracy and efficiency of resource access control and ultimately enhancing thread safety in multi-tasking environments. Detailed explanations follow.

[0027] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for implementing a reentrant lock according to an embodiment of the present invention. Wherein, Figure 1 The reentrant lock described in the reentrant lock implementation method refers to a locking mechanism where the same task can acquire the same lock multiple times without causing a deadlock. For example, when a task holds a lock and calls another function that also needs the lock, it will not be blocked. This reentrant lock implementation method can be applied to electronic devices with applications installed, where the electronic device is communicatively connected to a network attached storage device (NAT), and accesses the NAT through the application. This method is used to control shared resources in the electronic device or NAT. It can also be applied to a reentrant lock implementation device, which can be integrated into a smart device (such as a mobile phone) or exist independently of the smart device, such as being integrated into the control server corresponding to the smart device. This embodiment of the invention does not impose limitations. Figure 1 As shown, the implementation method of this reentrant lock may include the following operations: 101. Perform a preset identity mapping detection operation on the first task that triggers the lock request, and obtain the detection result.

[0028] In this embodiment of the invention, the identity mapping detection operation includes detecting the first task through a preset task identity mapping table. The task identity mapping table records the correspondence between a task identifier and the number of reentrant attempts to hold a lock. The task identifier can be a task ID, a string identifier used to uniquely identify each executing task, similar to an ID card number, used to distinguish different tasks and record their lock holding status. By setting a mapping relationship with the number of reentrant attempts to hold a lock, reentrancy is ensured. Specifically, through task ID mapping and a reentrancy counting mechanism, the same task can acquire the same lock multiple times without deadlock. For example, this functionality is achieved through the `ownerMap.set(taskId, count + 1)` step, which helps solve the problem of recursive calls that the seamless solution cannot handle.

[0029] 102. When the detection result indicates that the first task is a new task, based on the preset dual-lock architecture, the first task is controlled to acquire the master lock by executing preset atomic operations.

[0030] In this embodiment of the invention, optionally, the dual-lock architecture consists of a master lock and an operation lock. The master lock is used to instruct the first task to perform resource access control operations, and the operation lock is used to instruct the first task to perform state management operations.

[0031] In this embodiment of the invention, an atomic operation refers to a complete operation that cannot be interrupted; simply put, it either succeeds entirely or fails entirely. In a multi-tasking environment, atomic operations ensure data consistency and prevent data errors caused by concurrent access. Atomic operations can be implemented using the `Atomics.compareExchange` and `SharedArrayBuffer` methods. `SharedArrayBuffer` is a technique for sharing memory data among multiple tasks, allowing different tasks to directly access the same memory area, achieving efficient data sharing and synchronization. Therefore, using atomic operations helps ensure thread safety in the HarmonyOS multi-tasking environment and offers higher reliability compared to traditional flag-based schemes.

[0032] In this embodiment of the invention, the atomic operation `Atomics.compareExchange` can be used to attempt to acquire the master lock. Specifically, this operation changes the zeroth element of the `lockView` array from zero to 1; the master lock is only successfully acquired when the original value is zero. This non-interruptible nature of atomic operations ensures that even if multiple tasks execute simultaneously, only one task can successfully acquire the master lock.

[0033] In this embodiment of the invention, the master lock can be implemented using SharedArrayBuffer, which helps to ensure memory sharing and atomicity guarantees across tasks.

[0034] 103. When the first task successfully acquires the master lock, control the first task to acquire the operation lock.

[0035] In this embodiment of the invention, after the first task successfully acquires the master lock, it acquires the operation lock again to protect the modification operation of the mapping table, thereby reducing the occurrence of data inconsistency caused by other tasks modifying the mapping table at the same time.

[0036] 104. Based on the current scenario of the first task, the first task performs resource access control operations through the master lock and performs state management operations through the operation lock.

[0037] In this embodiment of the invention, the current scenario may optionally include one of the following: multi-task concurrent download scenario, cache management scenario, resource pool management scenario, and file operation scenario. This embodiment of the invention does not limit the scenario.

[0038] Specifically, for multi-task concurrent download scenarios, when multiple download tasks access the download queue simultaneously, the first task controls queue access through the master lock and protects queue state updates through operation locks; for cache management scenarios, when multiple tasks read and write to the cache simultaneously, the first task controls cache access permissions through the master lock and protects cache metadata modifications through operation locks; for resource pool management scenarios, in thread pools or connection pools, the first task controls resource allocation and reclamation through the master lock and protects resource state recording through operation locks; for file operation scenarios, when multiple tasks operate on the same file simultaneously, the first task ensures mutual exclusion of file access through the master lock and protects internal states such as file descriptors through operation locks.

[0039] 105. When the first task fails to acquire the master lock, the first task is added to a preset waiting queue.

[0040] In this embodiment of the invention, the waiting queue is either empty or includes at least one waiting task. When the waiting queue includes at least one waiting task, it also includes the waiting duration for each waiting task. The waiting task is a task waiting to request a lock; the waiting queue is used to indicate a wake-up operation for any of the waiting tasks.

[0041] In this embodiment of the invention, specifically, during the process of attempting to acquire the master lock for the first task through atomic operations, if it is detected that the lock is occupied by another task, it is determined that the first task has failed to acquire the master lock. Furthermore, when the first task fails to acquire the master lock, the task that failed to acquire the lock is encapsulated into a WaitQueueItem object, and this object contains at least one key piece of information such as task ID, timestamp, and resolve callback function. Subsequently, a waitQueue is implemented using an array structure, and new tasks are added to the tail of the queue using the push method to ensure first-come, first-served fairness. The task is then suspended using a Promise mechanism. Compared to the traditional polling method, this solution, based on the characteristic that tasks entering a waiting state do not occupy CPU resources, helps to reduce resource waste.

[0042] In this embodiment of the invention, specifically, when the waiting queue indicates a wake-up operation for the first task, the first task is woken up, thereby triggering the execution of a step based on a preset dual-lock architecture when the first task is woken up, and controlling the first task to acquire the master lock by executing preset atomic operations.

[0043] It is evident that implementation Figure 1The described reentrant lock implementation method provides a novel access control approach. Based on a dual-lock mechanism of atomic operations and task identity mapping, it controls the access of a task requesting a lock to shared resources. Specifically, it attempts to acquire the master lock for the requesting task through atomic operations. This allows the task to acquire the operation lock if it successfully acquires the master lock. Depending on the task's context, the task performs resource access control operations through the master lock and state management operations through the operation lock. This ensures the task can safely access shared resources, improving the accuracy and efficiency of resource access control and enhancing thread safety in a multi-tasking environment. Furthermore, if the task fails to acquire the master lock, it can be added to a waiting queue to await wake-up. By adding the requesting task to the waiting queue and asynchronously suspending it while it is occupied by another task, waiting to be woken up and acquire the master lock, it improves the timeliness and efficiency of subsequent tasks acquiring the master lock.

[0044] Example 2 Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for implementing a reentrant lock according to an embodiment of the present invention. Wherein, Figure 2 The reentrant lock described in the reentrant lock implementation method refers to a locking mechanism where the same task can acquire the same lock multiple times without causing a deadlock. For example, when a task holds a lock and calls another function that also needs the lock, it will not be blocked. This reentrant lock implementation method can be applied to electronic devices with applications installed, where the electronic device is communicatively connected to a network attached storage device (NAT), and accesses the NAT through the application. This method is used to control shared resources in the electronic device or NAT. It can also be applied to a reentrant lock implementation device, which can be integrated into a smart device (such as a mobile phone) or exist independently of the smart device, such as being integrated into the control server corresponding to the smart device. This embodiment of the invention does not impose limitations. Figure 2 As shown, the implementation method of this reentrant lock may include the following operations: 201. Obtain the first task identifier of the first task that triggered the request lock; and verify the validity of the first task identifier.

[0045] 202. When the verification is successful, query the first task through the task identity mapping table based on the first task identifier.

[0046] 203. When the first task is found to exist in the task identity mapping table, increment the reentry count value of the first task by 1, and determine that the detection result is that the first task is not a new task.

[0047] In this embodiment of the invention, the reentry count value is used to record the number of times the same task acquires the same lock. The count increases when the task acquires the lock multiple times and decreases when the lock is released. The lock resource is only truly released when the count is zero.

[0048] In this embodiment of the invention, specifically, the validity of the first task identifier (such as ID) is detected by the validateTaskId method, such as non-empty verification, type checking, and format verification, to ensure that only valid tasks can participate in subsequent lock operations. When the verification is successful, the task identity mapping table is queried under the protection of the operation lock. The task identity mapping table can be denoted as the ownerMap mapping table. If the first task identifier is found to exist in the mapping table, it means that it is a re-entry request of the same task, and the re-entry count value corresponding to the task is directly incremented by 1. If the first task identifier does not exist in the mapping table, it means that the first task is a new task requesting the lock, and the subsequent lock contention process needs to be entered. This unique task identifier mechanism enables accurate differentiation of lock holders, improving task execution security and operational continuity. It also enhances lock management efficiency and accuracy. For example, in recursive function calls, when a function recursively calls itself while holding a lock and needs to acquire the same lock again, the reentrancy mechanism prevents deadlocks. In nested method calls, when an outer method acquires a lock and then calls an inner method that also needs the same lock, execution is safe. In transaction processing, in database or file operations, a transaction may access the same resource multiple times; the reentrancy mechanism ensures operational continuity. In complex business logic scenarios, when multiple layers of business logic calls need to access the same shared resource, the complexity of lock management is avoided.

[0049] 204. When it is found that the first task does not exist in the task identity mapping table, the first task is identified as a new task and used as the detection result.

[0050] 205. When the detection result indicates that the first task is a new task, based on the preset dual-lock architecture, the first task acquires the master lock by executing preset atomic operations.

[0051] 206. When the first task successfully acquires the master lock, control the first task to acquire the operation lock.

[0052] 207. Based on the current scenario of the first task, the first task performs resource access control operations through the master lock and state management operations through the operation lock.

[0053] 208. When the first task fails to acquire the master lock, add the first task to the preset waiting queue.

[0054] In this embodiment of the invention, for other descriptions of steps 201-208, please refer to the detailed description of steps 101-105 in Embodiment 1. This embodiment of the invention will not repeat them.

[0055] It is evident that implementation Figure 2 The described reentrant lock implementation method provides a novel access control approach. Based on a dual-lock mechanism of atomic operations and task identity mapping, it controls the access of a task requesting a lock to shared resources. Specifically, it attempts to acquire the master lock for the requesting task through atomic operations. This allows the task to acquire the operation lock if it successfully acquires the master lock. Depending on the task's context, the task performs resource access control operations through the master lock and state management operations through the operation lock. This ensures the task can safely access shared resources, improving the accuracy and efficiency of resource access control and enhancing thread safety in a multi-tasking environment. Furthermore, if the task fails to acquire the master lock, it can be added to a waiting queue to await wake-up. By adding the requesting task to the waiting queue and asynchronously suspending it while it is occupied by another task, waiting to be woken up and acquire the master lock, it improves the timeliness and efficiency of subsequent tasks acquiring the master lock. In addition, it can obtain the first task identifier of the first task that triggered the lock request; and verify the validity of the first task identifier. When the verification is successful, it queries the first task through the task identity mapping table based on the first task identifier. When the first task exists in the task identity mapping table, it increments the reentrancy count of the first task by 1. When the first task does not exist in the task identity mapping table, it is identified as a new task. It can first verify the validity of the task identifier that requests the lock, and when the identifier of the task is valid, it further determines whether the task is a duplicate request for a lock that is already held. Based on the judgment result, it can flexibly choose to increase the reentrancy count or engage in lock contention.

[0056] In an optional embodiment, the first task is awakened from the waiting queue in the following manner: Based on the waiting time of all waiting tasks, determine the task wake-up order corresponding to the waiting queue. The task wake-up order is used to indicate the wake-up order of each waiting task in the waiting queue. When the master lock is released, the preset task wake-up function is called to wake up the currently waiting task in the wake-up order indicated by the task wake-up order, so as to trigger the currently waiting task to acquire the master lock. When the currently waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks is re-executed until the currently waiting task is the first task. When the currently waiting task is the first task and the master lock is released, wake up the first task.

[0057] In this embodiment of the invention, when a waiting task is added to the waiting queue, the timestamp of the task being added to the queue is recorded to provide a time reference for subsequent timeout detection. When the lock is released, a task wake-up function is called, such as the notifyNextWaiter method, which uses the shift method to retrieve the task with the longest waiting time from the head of the queue and executes its resolve callback to wake up the waiting task. Furthermore, the woken task re-attempts to acquire the lock, and if the task still fails at this time, it is added back to the waiting queue.

[0058] In this embodiment of the invention, the waiting queue can specifically be a FIFO queue. FIFO (First In First Out) means that the element added to the queue first is processed first. In the lock waiting queue, the task that requests the lock earliest will acquire the lock first, ensuring fairness. Thus, through the FIFO waiting queue and the sequential wake-up mechanism of the notifyNextWaiter method, fairness in task lock acquisition is ensured, avoiding the starvation problem that may occur in traditional solutions.

[0059] In this embodiment of the invention, optionally, a waiting task within a waiting queue is woken up to enable the waiting task to acquire the lock in a timely manner. Specifically, this can be applied to at least one of the following scenarios: high-concurrency API request scenarios, database connection pool scenarios, file upload queue scenarios, audio / video playback scenarios, and device access control scenarios. Specifically, for high-concurrency API request scenarios, the number of simultaneous requests to the backend API can be limited; requests exceeding the limit must queue and be processed sequentially. For database connection pool scenarios, when the connection pool is full (i.e., all connection channels within the pool are occupied), new database operation requests must queue and be allocated according to the waiting order when a connection is released. For file upload queue scenarios, the number of files uploaded simultaneously can be limited; multiple upload tasks must be executed sequentially according to the submission order. For audio / video playback scenarios, when multiple playback requests compete for player resources, they are queued for playback in the order of requests to avoid playback conflicts. For device access control scenarios, access requests for exclusive devices such as Bluetooth and cameras can be ensured to be accessed in an orderly manner through a queuing mechanism; this embodiment of the invention does not limit this.

[0060] For example, suppose all waiting tasks in waiting queue A are divided into waiting task a1, waiting task a2, and waiting task a3 according to the task wake-up order, and the first task requesting the lock is waiting task a3. Then, when the master lock is released, waiting task a1 is woken up first in the first-in-first-out order so that waiting task a1 can acquire the master lock. Then waiting task a1 is removed from the waiting queue so that when the master lock is released again, waiting task a2 will be the next task to be woken up. This process continues to achieve fair scheduling.

[0061] In this embodiment of the invention, optionally, when the number of locks to be released is greater than 1, a corresponding waiting queue can be set for each lock. When a lock is released, a task wake-up function is called to wake up the currently waiting task indicated by the task wake-up order in the waiting queue corresponding to that lock. For example, suppose there are lock 1 and lock 2, and lock 1 exists in the aforementioned waiting queue A, and lock 2 exists in a corresponding waiting queue B. Waiting queue B includes waiting tasks b1 and b2. When lock 1 and lock 2 are released simultaneously, waiting task a1 in the current wake-up order of waiting queue A and waiting task b1 in the current wake-up order of waiting queue B corresponding to lock 1 are simultaneously woken up.

[0062] As can be seen, this optional embodiment can automatically determine the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks, so as to indicate the wake-up order of each waiting task in the waiting queue. Thus, when the master lock is released, a preset task wake-up function is called to wake up the current waiting task, so as to trigger the current waiting task to acquire the master lock. When the current waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks is re-executed until the current waiting task becomes the first task. When the current waiting task becomes the first task and the master lock is released, the first task is woken up. This can improve the accuracy and reliability of waking up waiting tasks requesting the lock when the lock is occupied by other tasks, thereby improving the accuracy and timeliness of waiting tasks acquiring the lock.

[0063] In this optional embodiment, as an alternative implementation, the method may further include: Based on a preset timed detection mechanism, the status information of the main lock is detected once every preset time interval. The status information of the main lock is used to indicate the occupancy status of the main lock, which includes the occupied status or the unoccupied status. Based on the waiting time of all waiting tasks in the waiting queue, timeout tasks are identified in the waiting queue to obtain the identification results; and when the identification results indicate that there are timeout tasks in the waiting queue, the waiting tasks identified as timeout tasks are removed from the waiting queue to obtain a new waiting queue. Based on the master lock's status information, determine whether the master lock's current conditions meet the preset deadlock conditions; When it is determined that the current condition of the master lock meets the deadlock condition, the master lock is forcibly released, and for the new waiting queue, the preset task wake-up function is triggered to wake up the current waiting task in the current wake-up order indicated by the task wake-up order.

[0064] In this embodiment of the invention, the "occupied" state indicates that the lock is held by another task, and the "unoccupied" state indicates that the lock is not held by another task. The deadlock condition can be used to indicate the condition under which a lock is in the "occupied" state. Deadlock refers to a state where two or more tasks are mutually waiting for each other to release resources and are unable to continue execution. For example, task A holds lock 1 and waits for lock 2, while task B holds lock 2 and waits for lock 1, resulting in both tasks being indefinitely waiting.

[0065] In this embodiment of the invention, the timeout mechanism sets a maximum time limit for the task waiting lock. After the time limit is exceeded, the task automatically abandons the wait and returns failure, preventing the task from waiting indefinitely and wasting system resources.

[0066] In this embodiment of the invention, optionally, the monitoring of lock status and the identification, removal, and wake-up of waiting tasks are achieved through a timed detection mechanism and a timeout task identification function. Specifically, this can be applied to at least one of the following scenarios: network request timeout, task crash, long-running background task, system resource reclamation, and abnormal recovery. Specifically, for network request timeout scenarios, when a network request fails to acquire the lock due to timeout, the waiting state is automatically cleared, and a timeout error is returned to the upper-level caller. For task crash scenarios, if a task fails to execute `unlock` due to an abnormal crash while holding the lock, a timed checker can automatically detect and recover it, preventing other tasks from being permanently blocked. For long-running background task scenarios, a timeout mechanism can prevent background tasks that may run for extended periods from holding the lock for too long and affecting other tasks. For system resource reclamation scenarios, inactive waiting tasks can be periodically cleared to release memory resources in a timely manner, thereby maintaining system efficiency. For abnormal recovery scenarios, when the system experiences an abnormal state, a proactive monitoring and recovery mechanism can avoid manual intervention, thereby improving the system's self-healing capability.

[0067] Specifically, through the detection step of if (this.isLocked() && this.ownerMap.size === 0) in the timing checker, the deadlock state can be actively discovered and repaired. Compared with the passive waiting of the traditional solution, it is beneficial to improve the system stability. Also, through the time control mechanism of Date.now() - startTime < timeoutMs, it is beneficial to achieve precise timeout management of tasks. Compared with the traditional polling solution, it is beneficial to reduce CPU waste, thereby improving the system efficiency. For example, use the setInterval method to start a timing task, execute the check loop every 500 milliseconds to achieve continuous status monitoring; traverse the waitQueue waiting queue, calculate the waiting duration of each waiting task (for example: the current time minus the recorded timestamp), identify the waiting tasks that exceed 10 seconds as timeout tasks; then use the filter method to remove the timeout tasks from the queue, call its resolve callback to return a failure result, and prevent memory leaks caused by infinite waiting of tasks. In this way, by actively monitoring the lock status through the timing check mechanism, it is possible to automatically clean up the waiting tasks that have timed out, detect and recover the deadlock state, thereby improving the system stability. And the timing checker is automatically started when the lock object is constructed and runs continuously throughout its life cycle without manual triggering.

[0068] It can be seen that this optional implementation can detect the status information of the main lock based on a preset timing detection mechanism at a preset interval, and identify timeout tasks in the waiting queue based on the waiting durations of all waiting tasks in the waiting queue to obtain an identification result. Thus, combining the deadlock detection mechanism of lock status and timeout task identification, when it is detected that the main lock meets the deadlock condition, the main lock is forcibly released, and the process of waking up the waiting tasks is triggered. It can automatically clean up the waiting tasks that have timed out based on the timeout task identification mechanism, and can reduce the situation where the waiting tasks cannot be woken up in time due to the inability to release the lock normally and are misidentified as timeout tasks, resulting in task blocking.

[0069] In this optional implementation, optionally, judging whether the current condition of the main lock meets the preset deadlock condition according to the status information of the main lock includes: Detect the occupancy status of the main lock according to the status information of the main lock; When it is detected that the main lock is in an unoccupied state, it is determined that the current condition of the main lock does not meet the preset deadlock condition; When it is detected that the main lock is in an occupied state, detect the task identity mapping table; and when it is detected that the task identity mapping table is empty, it is determined that the current condition of the main lock meets the preset deadlock condition.

[0070] In this embodiment of the invention, specifically, when the lock is in an unoccupied state, it is determined that the lock does not meet the deadlock condition. The lock can be acquired by the currently awakened waiting task. Taking the aforementioned 500 milliseconds as an example, 500 milliseconds after the current task acquires the lock, the lock's status information is checked again to determine whether the lock meets the deadlock condition. When the lock is in an occupied state and the task identity mapping table is empty, for example, when the lockView array shows that the lock is occupied (value 1) but ownerMap is empty, it indicates that the task holding the lock terminated abnormally and did not release the lock normally, that is, the lock meets the deadlock condition. Furthermore, when a deadlock is detected, the Atomics.store method is used to reset the lockView array to zero to forcibly release the lock; then the notifyNextWaiter method is called to wake up the waiting task with the longest waiting time in the waiting queue.

[0071] As can be seen, this optional implementation can also detect the occupancy status of the master lock based on the master lock's status information. When the master lock is detected to be in an unoccupied state, it can directly determine that the current condition of the master lock does not meet the preset deadlock condition, which can improve the accuracy and efficiency of determining that the master lock does not meet the deadlock condition. When the master lock is detected to be in an occupied state, it can further detect the task identity mapping table. When the task identity mapping table is detected to be empty, it can determine that the current condition of the master lock meets the preset deadlock condition, which can improve the accuracy and reliability of determining that the master lock meets the deadlock condition.

[0072] In another alternative embodiment, the method may further include: Based on the obtained second task identifier, check whether the second task exists in the task identity mapping table; If the second task is detected to exist in the task identity mapping table, the reentry count value of the second task is decremented by 1 to determine whether the reentry count value of the second task is less than or equal to zero. When it is determined that the reentrancy count of the second task is less than or equal to zero, the second task will perform the lock release operation.

[0073] In this embodiment of the invention, optionally, the second task is the task that triggers the release of the lock. For example, for the aforementioned first task that requests the lock, after the first task acquires the master lock and completes its task content, if the first task triggers the lock release operation, then the second task is the first task; when the first task fails to acquire the master lock and is added to the waiting queue as a waiting task, if another task currently occupying the master lock triggers the lock release operation, then the second task is that other task. This embodiment of the invention does not limit the scope of the second task.

[0074] In this embodiment of the invention, specifically, firstly, it is verified that the task ID calling unlock exists in the ownerMap to ensure that only the lock holder can release the lock and prevent accidental operation; when the verification passes, the current reentrancy count value of the task is obtained, and it is decremented by 1 to obtain a new count value; then it is determined whether the new count value is less than or equal to zero. If it is less than or equal to zero, it means that the task has completely exited all reentrancy levels and needs to be truly released; when the lock is truly released, the record of the task is deleted from the ownerMap, and the lockView is reset to zero using the Atomics.store method; after releasing the lock, the notifyNextWaiter method is immediately called to wake up the next waiting task to ensure that the lock resource is not idle; if the new count value is greater than zero, it means that the task is still in a reentrancy state, and only the count value in the ownerMap is updated to maintain the lock holding state; furthermore, the entire release process is executed under the protection of the operation lock to ensure that multiple release operations do not interfere with each other.

[0075] In this embodiment of the invention, the scenario applicable to releasing the lock and waking up the next waiting task only when the task has completely exited and re-entered can optionally include at least one of the following: recursive function return scenario, nested transaction commit scenario, resource cleanup scenario, task completion notification scenario, and concurrency control scenario. Specifically, for the recursive function return scenario, `unlock` is called when the recursive function returns at each level, and the lock resource is only truly released when the outermost level returns; for the nested transaction commit scenario, the re-entry count is reduced when the inner transaction commits, and the database lock is only released when the outer transaction commits; for the task completion notification scenario, after the task completes and releases the lock, the next waiting task is automatically notified, realizing pipelined processing of tasks; for the concurrency control scenario, in scenarios requiring exclusive access, such as file operations and network requests, a proper lock release mechanism ensures the reasonable allocation of resources.

[0076] As can be seen, this optional embodiment can detect whether the second task exists in the task identity mapping table based on the obtained second task identifier. If the second task exists in the task identity mapping table, the re-entry count value of the second task is decremented by 1 to determine whether the re-entry count value of the second task is less than or equal to zero. When it is determined that the re-entry count value of the second task is less than or equal to zero, the second task performs the lock release operation. After verifying the task identity, the lock is safely released, and the re-entry count is decremented. This ensures that the lock resource is truly released and the next waiting task is woken up only when the re-entry is completely exited, which helps to improve the accuracy and reliability of lock resource release.

[0077] For example, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating another implementation method of a reentrant lock disclosed in an embodiment of the present invention, as shown below. Figure 3As shown, the method may specifically include the following steps: A task triggers a lock request; the task ID is verified, specifically whether the ID is valid; if not, a failure message is returned to the user / device / platform that triggered the task; if yes, the reentrancy of the task is further checked, such as by checking the reentrancy count value of the task, to determine whether the task is the same task currently holding the lock. When it is determined that it is the same task, the reentry count value of the task is increased directly and a success message is returned to the user / device / platform that triggered the task; When it is determined that they are not the same task, attempt to acquire the master lock and check whether the master lock is successfully acquired; if yes, set the task mapping and return a success message; if no, add the task to the waiting queue. The task waits in the queue to be woken up or to perform timeout detection. For example, it checks whether the task has timed out. If so, it returns a failure message to the user / device / platform that triggered the task. If not, it waits to be woken up and tries to acquire the lock again. This process is repeated.

[0078] Optional, such as Figure 3 As shown, the method may further include the following steps: Configure a timed checker to periodically clean up timed-out tasks and check for deadlocks and automatically recover them.

[0079] Optional, such as Figure 3 As shown, the method may further include the following steps: When a task triggers a request to release the lock, the task's identity is verified. If the verification is successful, the task's reentrancy count is decremented to obtain a new reentrancy count, and it is determined whether the new reentrancy count is zero. If not, the task's lock holding state is maintained. If so, the main lock is released and the next waiting party is woken up.

[0080] Example 3 Please see Figure 4 , Figure 4 This is a schematic diagram of a reentrant lock implementation device disclosed in an embodiment of the present invention. Wherein, Figure 4 The reentrant lock described in the reentrant lock implementation means that the same task can acquire the same lock multiple times without causing a deadlock. For example, when a task holds the lock and calls another function that also needs the lock, it will not be blocked. Furthermore, the reentrant lock implementation can be integrated into a smart device (such as a mobile phone) or can exist independently of the smart device, such as being integrated into the control server corresponding to the smart device. This embodiment of the invention does not impose any limitations. Figure 4 As shown, the implementation device for the reentrant lock may include: The detection module 301 is used to perform a preset identity mapping detection operation on the first task that triggers the request lock and obtain the detection result. The identity mapping detection operation includes the operation of detecting the first task through a preset task identity mapping table.

[0081] The acquisition module 302 is used to control the first task to acquire the master lock by executing a preset atomic operation based on a preset dual-lock architecture when the detection result indicates that the first task is a new task. The dual-lock architecture consists of a master lock and an operation lock. The master lock is used to instruct the first task to perform resource access control operations, and the operation lock is used to instruct the first task to perform state management operations.

[0082] The control module 303 is used to control the first task to acquire the operation lock when the first task successfully acquires the master lock, and to perform resource access control operations through the master lock and state management operations through the operation lock based on the current scenario of the first task.

[0083] The wake-up module 304 is used to add the first task to a preset waiting queue when the first task fails to acquire the master lock. The waiting queue is either empty or contains at least one waiting task, which is a task waiting to request the lock. The waiting queue is used to indicate the wake-up operation for any waiting task.

[0084] It is evident that implementation Figure 4 The described reentrant lock implementation provides a novel access control method. Based on a dual-lock mechanism of atomic operations and task identity mapping, it controls the access of a task requesting a lock to shared resources. Specifically, it attempts to acquire the master lock for the requesting task through atomic operations. If the task successfully acquires the master lock, it can then acquire the operation lock. Depending on the task's context, the task performs resource access control operations through the master lock and state management operations through the operation lock. This ensures that the requesting task can safely access shared resources, improving the accuracy and efficiency of resource access control and enhancing thread safety in a multi-tasking environment. Furthermore, if the task fails to acquire the master lock, it can be added to a waiting queue to await wake-up. By adding the requesting task to the waiting queue and asynchronously suspending it while it is occupied by other tasks, waiting to be woken up and acquire the master lock, it improves the timeliness and efficiency of subsequent tasks acquiring the master lock.

[0085] In this optional embodiment, as an optional implementation, when the waiting queue includes at least one waiting task, the waiting queue also includes the waiting duration for each waiting task. Furthermore, the first task is awakened in the waiting queue in the following manner: Based on the waiting time of all waiting tasks, determine the task wake-up order corresponding to the waiting queue. The task wake-up order is used to indicate the wake-up order of each waiting task in the waiting queue. When the master lock is released, the preset task wake-up function is called to wake up the currently waiting task in the wake-up order indicated by the task wake-up order, so as to trigger the currently waiting task to acquire the master lock. When the currently waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks is re-executed until the currently waiting task is the first task. When the currently waiting task is the first task and the master lock is released, wake up the first task.

[0086] As can be seen, this optional implementation can automatically determine the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks, so as to indicate the wake-up order of each waiting task in the waiting queue. Thus, when the master lock is released, a preset task wake-up function is called to wake up the current waiting task, so as to trigger the current waiting task to acquire the master lock. When the current waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all waiting tasks is re-executed until the current waiting task becomes the first task. When the current waiting task becomes the first task and the master lock is released, the first task is woken up. This can improve the accuracy and reliability of waking up waiting tasks requesting the lock when the lock is occupied by other tasks, thereby improving the accuracy and timeliness of waiting tasks acquiring the lock.

[0087] In this optional implementation, the detection module 301 is optionally further configured to detect the status information of the master lock once at preset time intervals based on a preset time detection mechanism. The status information of the master lock is used to indicate the occupancy status of the master lock, which includes an occupied state or an unoccupied state. And, as... Figure 5 As shown, Figure 5 This is a schematic diagram of another reentrant lock implementation device disclosed in an embodiment of the present invention, wherein the device may further include: The identification processing module 305 is used to identify timed-out tasks in the waiting queue based on the waiting time of all waiting tasks in the waiting queue and obtain the identification result; and when the identification result indicates that there are timed-out tasks in the waiting queue, the waiting tasks identified as timed-out tasks are removed from the waiting queue and a new waiting queue is obtained.

[0088] The deadlock detection module 306 is used to determine whether the current condition of the master lock meets the preset deadlock condition based on the master lock's state information.

[0089] The forced release module 307 is used to forcibly release the main lock when the deadlock judgment module 306 determines that the current condition of the main lock meets the deadlock condition, and to trigger the execution of the preset task wake-up function for the new waiting queue, so as to wake up the operation of the currently waiting task in the current wake-up order indicated by the task wake-up order.

[0090] As can be seen, the optional device can also detect the status information of the master lock once at a preset time interval based on a preset time detection mechanism, and identify timed-out tasks in the waiting queue based on the waiting time of all waiting tasks in the waiting queue. The identification result is obtained, and then the deadlock detection mechanism combining the lock status and timed-out task identification can forcibly release the master lock when the deadlock condition is detected, and trigger the process of waking up the waiting tasks. It can automatically clean up timed-out waiting tasks based on the timed-out task identification mechanism, and can reduce the occurrence of task blocking caused by waiting tasks not being woken up in time due to the lock not being able to be released normally.

[0091] In this optional implementation, further optionally, the deadlock determination module 306 determines whether the current condition of the master lock meets the preset deadlock condition based on the master lock's state information in the following specific ways: Based on the master lock's status information, detect the master lock's occupancy status; When it is detected that the master lock is in an unoccupied state, it is determined that the current condition of the master lock does not meet the preset deadlock condition; When the master lock is detected to be in an occupied state, the task identity mapping table is checked; and when the task identity mapping table is detected to be empty, it is determined that the current condition of the master lock meets the preset deadlock condition.

[0092] As can be seen, this optional implementation can also detect the occupancy status of the master lock based on the master lock's status information. When the master lock is detected to be in an unoccupied state, it can directly determine that the current condition of the master lock does not meet the preset deadlock condition, which can improve the accuracy and efficiency of determining that the master lock does not meet the deadlock condition. When the master lock is detected to be in an occupied state, it can further detect the task identity mapping table. When the task identity mapping table is detected to be empty, it can determine that the current condition of the master lock meets the preset deadlock condition, which can improve the accuracy and reliability of determining that the master lock meets the deadlock condition.

[0093] In another optional embodiment, a task identity mapping table is used to record the correspondence between a task identifier and the number of reentrant attempts to hold a lock. Furthermore, the detection module 301 performs a preset identity mapping detection operation on the first task that triggers the lock request, and the specific method for obtaining the detection result includes: Obtain the first task identifier of the first task that triggered the lock request; and verify the validity of the first task identifier; When the verification is successful, the first task is retrieved from the task identity mapping table based on the first task identifier; When the first task is found to exist in the task identity mapping table, the reentry count value of the first task is incremented by 1, and the detection result is determined to be that the first task is not a new task. If the first task is not found in the task identity mapping table, the first task is identified as a new task and used as the detection result.

[0094] As can be seen, this optional embodiment can obtain the first task identifier of the first task that triggers the lock request; and verify the validity of the first task identifier. When the verification is successful, the first task is queried through the task identity mapping table according to the first task identifier. When the first task is found to exist in the task identity mapping table, the reentrancy count value of the first task is incremented by 1. When the first task is not found to exist in the task identity mapping table, the first task is identified as a new task. It can first verify the validity of the task identifier that requests the lock, and when the identifier of the task is valid, it can further determine whether the task is a duplicate request for a lock that is already held. Thus, it can flexibly choose to increase the reentrancy count or engage in lock contention based on the judgment result.

[0095] In another optional embodiment, the detection module 301 is further configured to detect whether the second task exists in the task identity mapping table based on the obtained second task identifier of the second task, wherein the second task is the task that triggered the lock release. And, as... Figure 5 As shown, the device may further include: The reentrancy determination module 308 is used to determine whether the reentrancy count of the second task is less than or equal to zero by decrementing the reentrancy count of the second task by 1 if the second task is detected to exist in the task identity mapping table. The normal release module 309 is used to release the lock when the reentry judgment module 308 determines that the reentry count value of the second task is less than or equal to zero.

[0096] As can be seen, this optional embodiment can detect whether the second task exists in the task identity mapping table based on the obtained second task identifier. If the second task exists in the task identity mapping table, the re-entry count value of the second task is decremented by 1 to determine whether the re-entry count value of the second task is less than or equal to zero. When it is determined that the re-entry count value of the second task is less than or equal to zero, the second task performs the lock release operation. After verifying the task identity, the lock is safely released, and the re-entry count is decremented. This ensures that the lock resource is truly released and the next waiting task is woken up only when the re-entry is completely exited, which helps to improve the accuracy and reliability of lock resource release.

[0097] Example 4 Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention. Figure 6 As shown, the electronic device may include: Memory 401 storing executable program code; Processor 402 coupled to memory 401; The processor 402 calls the executable program code stored in the memory 401 to execute the steps in the reentrant lock implementation method described in Embodiment 1 or Embodiment 2 of the present invention.

[0098] Example 5 Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a reentrant lock implementation system disclosed in an embodiment of the present invention, as shown below. Figure 7 As shown, the system includes at least a reentrant lock implementation device 30 as described in Embodiment 3 of the present invention, and a network-attached storage device 50 communicatively connected to the reentrant lock implementation device 30. The network-attached storage device 50 stores shared resources. When the reentrant lock implementation device 30 triggers a target task to process the shared resources, the reentrant lock implementation device 30 performs control operations on the shared resources based on the reentrant lock implementation method described in Embodiment 1 or Embodiment 2 of the present invention and the target task. or, Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a reentrant lock implementation system disclosed in an embodiment of the present invention, as shown below. Figure 8 As shown, the system includes at least an electronic device 40 as described in Embodiment 3 of the present invention, and a network-attached storage device 50 that is communicatively connected to the electronic device 40. The network-attached storage device 50 stores shared resources. When the electronic device 40 triggers a target task to process the shared resources, the electronic device 40 performs control operations on the shared resources based on the target task and in accordance with the reentrant lock implementation method described in Embodiment 1 or Embodiment 2 of the present invention.

[0099] Example 6 This invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute the steps in the reentrant lock implementation method described in Embodiment 1 or Embodiment 2 of this invention.

[0100] Example 7 This invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the steps in the reentrant lock implementation method described in Embodiment 1 or Embodiment 2.

[0101] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0102] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0103] Finally, it should be noted that the reentrant lock implementation method and apparatus disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for implementing a reentrant lock, characterized in that, The method is applied to an electronic device with an application installed, and the electronic device is communicatively connected to a network attached storage device (NETS), accessing the NETS via the application. The method is used to control shared resources in the electronic device or the NETS; wherein the method includes: A preset identity mapping detection operation is performed on the first task that triggers the lock request to obtain the detection result. The identity mapping detection operation includes the operation of detecting the first task through a preset task identity mapping table. When the detection result indicates that the first task is a new task, based on the preset dual-lock architecture, the first task is controlled to acquire the master lock by executing a preset atomic operation. The dual-lock architecture consists of the master lock and the operation lock. The master lock is used to instruct the first task to perform the resource access control operation, and the operation lock is used to instruct the first task to perform the state management operation. When the first task successfully acquires the master lock, it is controlled to acquire the operation lock. Based on the current scenario of the first task, the first task performs resource access control operations through the master lock and performs state management operations through the operation lock. When the first task fails to acquire the master lock, the first task is added to a preset waiting queue. The waiting queue is either empty or includes at least one waiting task, which is a task waiting to request a lock. The waiting queue is used to indicate a wake-up operation for any of the waiting tasks.

2. The method for implementing a reentrant lock according to claim 1, characterized in that, When the waiting queue includes at least one of the waiting tasks, the waiting queue also includes the waiting time for each of the waiting tasks; Furthermore, the first task is awakened in the waiting queue in the following manner: Based on the waiting time of all the waiting tasks, the task wake-up order corresponding to the waiting queue is determined, and the task wake-up order is used to indicate the wake-up order of each of the waiting tasks in the waiting queue. When the master lock is released, a preset task wake-up function is called to wake up the currently waiting task in the current wake-up order indicated by the task wake-up order, so as to trigger the currently waiting task to acquire the master lock. When the currently waiting task successfully acquires the master lock, the operation of determining the task wake-up order corresponding to the waiting queue based on the waiting time of all the waiting tasks is re-executed until the currently waiting task is the first task. When the currently waiting task is the first task and the master lock is released, the first task is awakened.

3. The method for implementing a reentrant lock according to claim 2, characterized in that, The method further includes: Based on a preset timed detection mechanism, the status information of the master lock is detected once at preset intervals. The status information of the master lock is used to indicate the occupancy status of the master lock, which includes an occupied status or an unoccupied status. Based on the waiting time of all the waiting tasks in the waiting queue, timeout tasks are identified in the waiting queue to obtain an identification result; and when the identification result indicates that there are timeout tasks in the waiting queue, the waiting tasks identified as timeout tasks are removed from the waiting queue to obtain a new waiting queue. Based on the status information of the master lock, determine whether the current condition of the master lock meets the preset deadlock condition; When it is determined that the current condition of the master lock meets the deadlock condition, the master lock is forcibly released, and for the new waiting queue, the preset task wake-up function is triggered to wake up the operation of the currently waiting task in the current wake-up order indicated by the task wake-up order.

4. The method for implementing a reentrant lock according to claim 3, characterized in that, The step of determining whether the current condition of the master lock meets the preset deadlock condition based on the master lock's state information includes: Based on the status information of the master lock, detect the occupancy status of the master lock; When it is detected that the master lock is in the unoccupied state, it is determined that the current condition of the master lock does not meet the preset deadlock condition; When the master lock is detected to be in the occupied state, the task identity mapping table is checked; and when the task identity mapping table is detected to be empty, it is determined that the current condition of the master lock meets the preset deadlock condition.

5. The method for implementing a reentrant lock according to any one of claims 1-4, characterized in that, The task identity mapping table is used to record the correspondence between the task identifier and the number of reentries of the lock it holds; And, the first task that triggers the request lock performs a preset identity mapping detection operation to obtain the detection result, including: Obtain the first task identifier of the first task that triggered the lock request; and verify the validity of the first task identifier; When the verification is successful, the first task is queried through the task identity mapping table based on the first task identifier; When the first task is found to exist in the task identity mapping table, the reentry count value of the first task is incremented by 1, and the detection result is determined to be that the first task is not a new task. When it is found that the first task does not exist in the task identity mapping table, the first task is identified as a new task and used as the detection result.

6. The method for implementing a reentrant lock according to claim 5, characterized in that, The method further includes: Based on the obtained second task identifier, check whether the second task exists in the task identity mapping table; the second task is the task that triggers the lock release. If the second task is detected to exist in the task identity mapping table, the reentry count value of the second task is decremented by 1 to determine whether the reentry count value of the second task is less than or equal to zero. When it is determined that the reentrancy count value of the second task is less than or equal to zero, the second task performs the lock release operation.

7. A device for implementing a reentrant lock, characterized in that, The device is used in an electronic device with an application installed, and the electronic device is communicatively connected to a network-attached storage device (NATD) and accesses the NATD through the application. The device is used to control shared resources in the electronic device or the NATD; wherein the device includes: The detection module is used to perform a preset identity mapping detection operation on the first task that triggers the request lock and obtain the detection result. The identity mapping detection operation includes the operation of detecting the first task through a preset task identity mapping table. The acquisition module is used to control the first task to acquire the master lock by executing a preset atomic operation based on a preset dual-lock architecture when the detection result indicates that the first task is a new task. The dual-lock architecture consists of the master lock and the operation lock. The master lock is used to instruct the first task to execute the resource access control operation, and the operation lock is used to instruct the first task to execute the state management operation. The control module is used to control the first task to acquire the operation lock when the first task successfully acquires the master lock, and to have the first task perform resource access control operations through the master lock and state management operations through the operation lock based on the current scenario of the first task. The wake-up module is used to add the first task to a preset waiting queue when the first task fails to acquire the master lock. The waiting queue is either empty or includes at least one waiting task, which is a task waiting to request the lock. The waiting queue is used to indicate the wake-up operation for any of the waiting tasks.

8. An electronic device, characterized in that, The electronic device includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the reentrant lock implementation method as described in any one of claims 1-6.

9. A system for implementing a reentrant lock, characterized in that, The system includes at least the reentrant lock implementation apparatus as described in claim 7, and a network-attached storage device communicatively connected to the reentrant lock implementation apparatus, wherein the network-attached storage device stores shared resources. When the reentrant lock implementation apparatus triggers a target task that processes the shared resources, the reentrant lock implementation apparatus performs a control operation on the shared resources based on the reentrant lock implementation method as described in any one of claims 1-6 and the shared resources; or, The system includes at least the electronic device as described in claim 8, and a network-attached storage device communicatively connected to the electronic device, wherein the network-attached storage device stores shared resources, and when the electronic device triggers a target task to process the shared resources, the electronic device performs a control operation on the shared resources based on the reentrant lock implementation method as described in any one of claims 1-6 and the shared resources.

10. A computer storage medium, characterized in that, The computer storage medium stores computer instructions, which, when invoked, are used to execute the implementation method of the reentrant lock as described in any one of claims 1-6.

Images