Read lock state determination method and device, equipment and storage medium
By assigning a target index to each thread and establishing a mapping relationship between the thread and the read lock holding object table, the problem of low efficiency in traditional read lock state acquisition is solved, and efficient location and clearing of read lock states is achieved, thereby improving the overall performance of the system.
Patent Information
- Application Number
- CN202511554326.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-28
- Publication Date
- 2026-02-10
AI Technical Summary
Traditional lock state acquisition is inefficient, impacting system performance, especially under high-frequency operations.
Assign a target index to each thread to establish a unique mapping relationship between the thread and the read lock holding object table. Record and clear thread information through the target index to eliminate the dynamic lookup process and improve the efficiency and accuracy of read lock status determination.
By using the target index, efficient location and clearing of read lock status is achieved, avoiding the accumulation of invalid data, improving the efficiency and accuracy of reading lock status determination, and preventing status record conflicts and data overwriting.
Smart Images
Figure CN121501439A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of resource access technology, and in particular to a method, apparatus, device and storage medium for determining read lock status. Background Technology
[0002] A read-write lock is a thread synchronization mechanism used to manage concurrent access to shared resources. Its core design distinguishes between read and write operations to improve concurrency performance, making it particularly suitable for read-heavy, write-light scenarios. A write lock allows only one thread to acquire it at a time, and holding a write lock blocks all read / write operations. A read lock, on the other hand, allows multiple threads to acquire the lock simultaneously, enabling and sending read requests to the resource. Read lock states are typically used for thread priority diagnostics or load monitoring.
[0003] However, in the traditional approach, the information of the lock holder, i.e. thread information, is usually recorded by reading event logs. This results in low efficiency in acquiring the lock state under high-frequency operations, which affects the overall performance bottleneck of the system. Summary of the Invention
[0004] Therefore, it is necessary to provide a method, apparatus, device, and storage medium for determining the read lock status to address the aforementioned technical problems, thereby improving the efficiency of read lock status acquisition.
[0005] Firstly, this application provides a method for determining the state of a read lock, including:
[0006] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0007] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0008] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0009] In this embodiment, by introducing read lock state records and assigning a target index to at least one thread, a unique and definite mapping relationship is established for each thread in the read lock holding object table. This transforms thread identity into a data identifier that can be used for addressing, providing a foundation for subsequent determination of read lock states. When a target thread adds a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target thread's target index. This achieves the location and writing of the thread's read lock state, eliminating the dynamic lookup process of traversing read events to record the state and improving the efficiency of reading lock state determination. When the target thread releases the read lock, the target thread's thread information is cleared from the read lock holding object table, ensuring that the read lock holding object table only includes currently valid read lock holder information, i.e., thread information. This avoids the accumulation of invalid data and improves the accuracy of the recorded read lock states.
[0010] In one embodiment, allocating a target index for at least one thread includes: for each thread, obtaining a thread identifier of the thread; if the thread identifier is not included in the allocated thread group and the allocated thread group is full, identifying inactive threads in the allocated thread group; removing inactive threads from the allocated thread group; allocating a corresponding target index for the thread identifier, and storing the thread identifier in the allocated thread group.
[0011] In this embodiment, for each thread, a thread identifier is obtained; if the thread identifier is not included in the allocated thread group and the allocated thread group is full, inactive threads in the allocated threads are identified. This allows for the identification of reclaimable idle resources, i.e., inactive threads, when the target index resources are exhausted, thereby creating conditions for releasing storage space and accepting new threads, and avoiding allocation failures due to insufficient resources. By removing inactive threads from the allocated thread group, dynamic reuse and recycling of limited resources are achieved. By allocating a corresponding target index to the thread identifier and storing the thread identifier in the allocated thread group, the mapping between new threads and target indexes is achieved, as well as the updating of the global management state of the allocated thread group.
[0012] In one embodiment, after removing inactive threads from the allocated thread group, the method further includes: determining that the target index allocated to the inactive thread is invalid.
[0013] In this embodiment, by removing inactive threads from the allocated thread group, the target index allocated to the inactive thread is determined to be invalid, thereby severing the mapping relationship between the target index and the corresponding inactive thread, making the target index a free resource that can be reallocated, and preventing the inactive thread from continuing to use the target index, which would lead to an error in the read lock state record.
[0014] In one embodiment, the method further includes: allocating a corresponding target index for the thread identifier when the thread identifier is not included in the allocated thread group and the allocated thread group is not full; and storing the thread identifier in the allocated thread group.
[0015] In this embodiment of the application, by allocating a corresponding target index to a thread identifier when the thread identifier is not included in the allocated thread group and the allocated thread group is not full; and by storing the thread identifier in the allocated thread group, the mapping between the new thread and the target index and the update of the global management state of the allocated thread group are realized.
[0016] In one embodiment, the method further includes at least one of the following: if the thread identifier does not match the thread pool metadata, determine that the target index corresponding to the thread identifier is invalid and output a first exception alarm; if the thread identifier is duplicated, output a second exception alarm.
[0017] In this embodiment, by determining that the target index corresponding to the thread identifier is invalid when the thread identifier does not match the thread pool metadata, thread identifier identification and exception alerts are achieved, avoiding read lock state record errors caused by assigning target indexes to threads that do not belong to the thread pool metadata. By outputting a second exception alert when the thread identifier is duplicated, the same thread identifier is prevented from being mapped to multiple target indices, eliminating potential state record conflicts and data overwriting problems, and achieving self-diagnosis and error isolation capabilities.
[0018] In one embodiment, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread, including at least one of the following: if the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is recorded in the associated position of the target index in the read lock holding object table; if the target thread has not been allocated a target index, a target index is allocated to the target thread; if the target index is valid, the thread information of the target thread is recorded in the associated position of the target index in the read lock holding object table.
[0019] In this embodiment, the target index allocation for new threads and the location of thread information recording positions are implemented, which helps to improve recording efficiency. At the same time, by identifying the validity of the target index, the recording of thread information in the read lock holding object table is avoided when the target index is valid, thus eliminating problems such as state recording conflicts and data overwriting.
[0020] In one embodiment, clearing the thread information of the target thread from the read lock holding object table includes: clearing the thread information of the target thread from the read lock holding object table if the target thread has been allocated a target index and the target index is valid.
[0021] In this embodiment of the application, when the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table, thereby realizing the condition confirmation of the clearing operation and avoiding the situation of read lock holding object table update disorder.
[0022] Secondly, this application also provides a lock read status determination device, comprising:
[0023] An allocation module is used to allocate a target index to at least one thread; the target index is used to characterize the associated position of the thread in the read lock holding object table;
[0024] The recording module is used to record the thread information of the target thread in the read lock holding object table according to the target index of the target thread when the target thread adds a read lock in at least one thread.
[0025] The clearing module is used to remove the target thread's thread information from the read lock holding object table when the target thread releases the read lock.
[0026] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0027] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0028] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0029] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0030] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:
[0031] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0032] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0033] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0034] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:
[0035] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0036] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0037] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table. Attached Figure Description
[0038] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0039] Figure 1A This is a flowchart illustrating a method for determining the read lock state in one embodiment;
[0040] Figure 1B This is a schematic diagram of the static structure in one embodiment;
[0041] Figure 1C This is a schematic diagram illustrating the process of generating the read lock holding object table in one embodiment;
[0042] Figure 1D This is a flowchart illustrating the steps for recording thread information in one embodiment;
[0043] Figure 1E This is a flowchart illustrating the thread information clearing steps in one embodiment;
[0044] Figure 2A This is a flowchart illustrating the target index allocation steps in one embodiment;
[0045] Figure 2B This is a schematic diagram of the data storage structure for an index generator;
[0046] Figure 2C This is a flowchart illustrating the target index allocation steps in another embodiment;
[0047] Figure 3 This is a flowchart illustrating the read lock state determination method in another embodiment;
[0048] Figure 4 This is a structural block diagram of a lock read status determination device in one embodiment;
[0049] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0051] In one embodiment, such as Figure 1A As shown, a method for determining the read lock state is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:
[0052] S110. Assign a target index to at least one thread; the target index is used to characterize the associated position of the thread in the read lock holding object table.
[0053] The target index can be understood as an identifier used to represent the associated position of a thread in the read lock holding object table. By assigning a target index to at least one thread, a mapping relationship between the thread and the record position is established, which is also the associated position in the read lock holding object table.
[0054] The read lock holding object table can be understood as a record table used to record the information of the thread currently holding the read lock, i.e., the holder structure data. The read lock holding object table includes multiple record positions (i.e., associated positions) used to record thread information, and each record position corresponds to a target index.
[0055] For example, the target index can be represented in the form of a position sequence or position identifier, and the read lock holding object table can be represented in the form of a structured array or set. This application does not impose any restrictions on the specific representation of the target index and the read lock holding object table.
[0056] In an optional embodiment, the maximum number of threads in each thread pool can be obtained; the sum of the maximum number of threads in each thread pool is used as the holder length of the read lock holding object table, which is also the number of target indexes or associated positions.
[0057] For example, the holder length can be expressed by the following formula:
[0058] Size=Sum(MaxThread(ThreadPool-x));
[0059] Where Size represents the holder length, Sum represents the summation; MaxThread(ThreadPool-x) represents the maximum number of threads in the x-th thread pool; and x represents the thread pool number or index.
[0060] In an optional embodiment, a target index can be assigned to threads in the thread pool using an index generator; and a read lock holding object table can be generated using a Holder generator.
[0061] refer to Figure 1B The diagram shown is a static structural schematic. Wherein, Figure 1B The diagram shows how to assign target indices "index" to threads 1 through n using an index generator. For example, assigning target index "1" to thread 1 and target index "n" to thread n.
[0062] Figure 1B The document also demonstrates how a Holder generator can be used to construct a read lock holding object table for each read-write lock. Taking thread 1 with the thread name "t1" and the target index "1" as an example, when thread 1 adds the target read lock, "t1" can be recorded at the first record position in the read lock holding object table corresponding to the target read lock, indicating that thread 1 is among the holders of the target read lock. The same logic applies to other threads, and will not be elaborated further here.
[0063] refer to Figure 1C The diagram illustrates the process of generating the read lock holding object table. After system startup, the Holder generator is initialized to determine the holder length; the index generator is initialized; and a holder is added for each read-write lock (including read locks), forming the read lock holding object table.
[0064] Optionally, after assigning a target index to at least one thread, the target index can be saved to the local variable of the corresponding thread.
[0065] Optionally, the index generator may store allocated thread groups, which record thread information of the allocated threads. The thread information may include thread identifiers, such as thread names.
[0066] For example, when allocating a target index to a target thread, the thread information of the target thread can be compared with the thread information recorded in the allocated thread group to determine whether the target thread has completed the allocation of the target index; if so, the target index allocation will not be performed; if not, the target index allocation will be performed.
[0067] For example, the allocated thread group can be set with a thread number threshold; if the number of allocated threads in the allocated thread group is greater than the thread number threshold, the inactive threads (i.e. idle threads) in the allocated threads are released, and the target index allocated to the inactive threads is determined to be invalid, thereby realizing the dynamic reuse and recycling of limited resources.
[0068] In another optional embodiment, an expiration period can be set for the assigned target index, thereby determining the target index as invalid if the holding time corresponding to the target index exceeds a preset time length. The expiration period can be set through extensive experimentation or as needed, and this application does not impose any limitations on it.
[0069] S120. If a target thread in at least one thread adds a read lock, record the thread information of the target thread in the read lock holding object table according to the target index of the target thread.
[0070] Read-write locks (including read locks and write locks) are a thread synchronization mechanism used to manage concurrent access to shared resources. Their core design distinguishes between read and write operations to improve concurrency performance.
[0071] A read lock can be understood as a shared lock that allows multiple threads to acquire the read lock simultaneously, enabling concurrent reading of resources. In other words, multiple read lock contenders will not mutually exclude each other.
[0072] A write lock can be understood as an exclusive lock, allowing only one thread to acquire the write lock at a time. Holding a write lock will block all read / write operations. In other words, read lock contenders and write lock contenders are mutually exclusive, and multiple write lock contenders are mutually exclusive.
[0073] The thread information of the target thread may include a thread identifier, which may include at least one of a thread name and a thread identifier. Optionally, the thread information may also include at least one of a thread type and thread parameter information. This application does not limit the specific content of the thread information.
[0074] In one optional embodiment, if a target index has been allocated to the target thread and the target index is valid, the thread information of the target thread can be recorded at the associated position of the target index in the read lock holding object table. In another optional embodiment, if a target index has not been allocated to the target thread, a target index can be allocated to the target thread; if the target index is valid, the thread information of the target thread can be recorded at the associated position of the target index in the read lock holding object table.
[0075] Understandably, by identifying the validity of the target index, recording thread information in the read lock holding object table is avoided when the target index is valid, thus eliminating issues such as state record conflicts and data overwriting. Recording the target thread's thread information at the associated position of the target index in the read lock holding object table allows for precise location of thread information recording, improving recording efficiency. Allocating the target index to the target thread when it is not yet allocated ensures the allocation of the target index for the new thread.
[0076] refer to Figure 1D The diagram illustrates the process of recording thread information. When the target thread acquires a read lock, it determines whether a target index has been allocated. If an index exists, its validity is checked. If valid, the thread name is recorded at the associated position of the target index in the holder; otherwise, the process ends. Conversely, if no target index exists, an index is requested from the index generator and saved. The validity of the target index is then determined. If valid, the thread name is recorded at the associated position of the target index in the holder; otherwise, the process ends.
[0077] S130. If the target thread releases the read lock, remove the target thread's thread information from the read lock holding object table.
[0078] In an optional embodiment, if the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table. This achieves conditional confirmation of the clearing operation and avoids the possibility of incorrect updates to the read lock holding object table.
[0079] refer to Figure 1E The diagram illustrates the process of clearing thread information. When the target thread releases the read lock, it can be determined whether the target thread has been allocated a target index. If a target index is allocated, its validity is checked. If valid, the thread name is cleared at the associated position of the target index in the holder; if invalid, the process ends. Conversely, if no target index is allocated, the process ends.
[0080] In an optional embodiment, in the event of a deadlock in accessing resources, the thread information of each target thread recorded in the read lock holding object table and the thread information corresponding to the write lock can be obtained; a directed graph can be constructed based on the thread information of each target thread recorded in the read lock holding object table and the thread information corresponding to the write lock; and the circular dependency relationship of read and write locks can be determined based on the directed graph to identify the deadlock state.
[0081] Understandably, the thread information of each target thread recorded in the read lock holding object table is the read-write holder information, and the thread information corresponding to the write lock is the write lock holder information. By determining the directed graph based on the read-write holder information and the write lock holder information, it is possible to quickly determine the circular dependency relationship of read-write locks and thus identify deadlock states.
[0082] The aforementioned method for determining read lock states introduces read lock state records and assigns a target index to at least one thread. This establishes a unique and definite mapping relationship for each thread in the read lock holding object table, transforming thread identity into a data identifier that can be used for addressing, thus providing a foundation for subsequent read lock state determination. When a target thread adds a read lock, its thread information is recorded in the read lock holding object table based on the target thread's target index. This achieves the location and writing of the thread's read lock state, eliminating the dynamic lookup process of traversing read events to record the state and improving the efficiency of read lock state determination. When the target thread releases the read lock, its thread information is removed from the read lock holding object table, ensuring that the table only includes currently valid read lock holder information, i.e., thread information. This avoids the accumulation of invalid data and improves the accuracy of the recorded read lock state.
[0083] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the allocation steps of the target index are refined.
[0084] See Figure 2A The steps for allocating the target index shown include:
[0085] S210. For each thread, obtain the thread identifier of the thread.
[0086] Referring to the foregoing, a thread identifier may include at least one of the following: thread name and thread identifier.
[0087] S220. If the allocated thread group does not include a thread identifier and the allocated thread group is full, determine the inactive threads in the allocated thread group.
[0088] The allocated thread group can be understood as the set of thread identifiers assigned to the target index.
[0089] For example, the allocated thread group can be represented as a structured array or collection. This application does not impose any limitation on the specific representation of the allocated thread group.
[0090] For example, if the thread identifier matches the thread pool metadata, the thread identifier can be compared with the thread identifier of the corresponding allocated thread in the allocated thread group; thereby identifying the inactive thread in the allocated thread group if the allocated thread group does not include the thread identifier and the allocated thread group is full.
[0091] As mentioned above, the allocated thread group can be set with a thread count threshold; when the number of allocated threads (that is, the number of thread identifiers of allocated threads) in the allocated thread group reaches the thread count threshold, it means that the allocated thread group is full.
[0092] In an optional embodiment, if the thread identifier does not match the thread pool metadata, the target index corresponding to the thread identifier can be determined to be invalid, and a first exception alarm can be output. This realizes the identification of the thread identifier and the exception alarm, avoids the misregistration of read lock status records caused by allocating target indexes to threads that do not belong to the thread pool metadata, and realizes the ability of self-diagnosis and error isolation.
[0093] In an optional embodiment, a second exception alarm can be output in the event of duplicate thread identifiers, thereby preventing the same thread identifier from being mapped to multiple target indices, eliminating potential state record conflicts and data overwriting issues, and achieving self-diagnosis and error isolation capabilities.
[0094] refer to Figure 2B The diagram shows the data storage structure of the index generator. The index generator can store an array of thread names and thread pool metadata. The array of thread names represents the allocated thread groups.
[0095] Optionally, the thread pool metadata may include triplet information for each thread pool. The triplet information may include the thread name, maximum number of threads, and the starting number of the target index. Figure 2B The example illustrates two thread pools in the thread pool metadata, namely "tp-1-%d" and "tp-2-%d". Here, "%d" represents a sequence of integers starting from 0.
[0096] For example, when the thread name rule is "tp-x-%d", the thread names generated by this thread pool are an increasing sequence, such as "tp-x-0,tp-x-1,tp-x-2 …tp-xn".
[0097] Continue to refer to Figure 2BFor the first thread pool with thread name "tp-1-%d", its triplet information can be represented as "tp-1-%d,5,0", indicating that the maximum number of threads in this thread pool is 5, and the starting index is 0. For the first thread pool with thread name "tp-2-%d", its triplet information can be represented as "tp-2-%d,5,5", indicating that the maximum number of threads in this thread pool is 5, and the starting index is 5.
[0098] Figure 2B The diagram shows that the allocated thread group includes three threads from the first thread pool, whose thread names are recorded starting from index "0", and are "tp-1-0", "tp-1-1", and "tp-1-2" respectively. The allocated thread group also includes five threads from the second thread pool, whose thread names are recorded starting from index "5", and are "tp-2-0", "tp-2-1", "tp-1-2", "tp-2-3", and "tp-2-4" respectively.
[0099] The target thread's name index in the assigned thread group is also the target index of that thread in the Holder, meaning the target index is unique for each thread.
[0100] S230. Remove inactive threads from the assigned thread group.
[0101] In an optional embodiment, after removing inactive threads from the allocated thread group, it is determined that the target index allocated to the inactive threads may be invalid.
[0102] Understandably, by determining that the target index already allocated by an inactive thread is invalid, the mapping relationship between the target index and the corresponding inactive thread is severed, making the target index a free resource that can be reallocated. This prevents the inactive thread from continuing to use the target index, which could lead to errors in the read lock state record.
[0103] S240. Assign the corresponding target index to the thread identifier and store the thread identifier in the assigned thread group.
[0104] In an optional embodiment, if the thread identifier is not included in the allocated thread group and the allocated thread group is not full, a corresponding target index is allocated to the thread identifier; and the thread identifier is stored in the allocated thread group, thereby realizing the mapping between the new thread and the target index, as well as the update of the global management state of the allocated thread group.
[0105] refer to Figure 2CThe diagram illustrates the allocation steps for the target index in another embodiment. Specifically, thread names can be matched against thread pool metadata; if a match fails, an invalid index is returned; if a match succeeds, it is determined whether the currently allocated thread group contains the thread name; if it does, an invalid index is returned; if it does not, it is determined whether the allocated thread group is full; if not, an empty slot in the allocated thread group is queried, the thread name is stored in that slot, and a valid index is returned; if the group is full, the threads in the allocated thread group are scanned, the names of inactive threads are cleared, an empty slot in the allocated thread group is queried, the thread name is stored in that slot, and a valid index is returned.
[0106] In the target index allocation steps described above, the thread identifier of each thread is obtained. If the thread identifier is not included in the allocated thread group and the allocated thread group is full, inactive threads in the allocated thread group are identified. This allows for the identification of reclaimable idle resources, i.e., inactive threads, when the target index resources are exhausted, thus creating conditions for releasing storage space and accepting new threads, avoiding allocation failures due to insufficient resources. By removing inactive threads from the allocated thread group, dynamic reuse and recycling of limited resources are achieved. By allocating the corresponding target index to the thread identifier and storing the thread identifier in the allocated thread group, the mapping between new threads and target indexes is achieved, as well as the updating of the global management state of the allocated thread group.
[0107] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the method for determining the read lock state is described in detail.
[0108] See Figure 3 The following is a method for determining the read lock state in another embodiment, including:
[0109] S310. Determine the target length of the read lock holding object table based on the sum of the maximum number of threads in each thread pool.
[0110] The target length (holder length) is the maximum number of record positions that the read lock holding object table can accommodate, which is also the total number of target indexes.
[0111] S320. Construct a read lock holding object table based on the target length; associate the record position in the read lock holding object table with the target index; the target index is used to represent the associated position of the thread in the read lock holding object table.
[0112] S330. For each thread, obtain the thread identifier of the thread.
[0113] S340. If the allocated thread group does not include a thread identifier and the allocated thread group is full, determine the inactive threads in the allocated thread group.
[0114] Optionally, if the thread identifier is not included in the allocated thread group and the allocated thread group is not full, the corresponding target index is allocated for the thread identifier; and the thread identifier is stored in the allocated thread group.
[0115] Optionally, if the thread identifier does not match the thread pool metadata, determine that the target index corresponding to the thread identifier is invalid and output the first exception alarm;
[0116] Optionally, a second exception warning can be output if the thread identifier is duplicated.
[0117] S350. Remove inactive threads from the allocated thread group; determine that the target index allocated to inactive threads is invalid.
[0118] S360. Assign the corresponding target index to the thread identifier and save the thread identifier in the assigned thread group.
[0119] S370A. If a read lock is added to the target thread in at least one thread, and the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is recorded at the associated position of the target index in the read lock holding object table.
[0120] S370B: If a read lock is added to the target thread in at least one thread, and the target thread has not been allocated a target index, a target index is allocated to the target thread; if the target index is valid, the thread information of the target thread is recorded in the associated position of the target index in the read lock holding object table.
[0121] S380. If the target thread releases the read lock, and the target thread has been allocated a target index and the target index is valid, then the thread information of the target thread is cleared from the read lock holding object table.
[0122] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0123] Based on the same inventive concept, this application also provides a read lock state determination device for implementing the read lock state determination method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more read lock state determination device embodiments provided below can be found in the limitations of the read lock state determination method described above, and will not be repeated here.
[0124] In one exemplary embodiment, such as Figure 4 As shown, a read lock state determination device is provided, including: an allocation module 410, a recording module 420, and a clearing module 430, wherein:
[0125] The allocation module 410 is used to allocate a target index to at least one thread; the target index is used to characterize the associated position of the thread in the read lock holding object table;
[0126] The recording module 420 is used to record the thread information of the target thread in the read lock holding object table according to the target index of the target thread when the target thread adds a read lock in at least one thread.
[0127] The clearing module 430 is used to clear the thread information of the target thread from the read lock holding object table when the target thread releases the read lock.
[0128] In one embodiment, the allocation module 410 includes: an acquisition unit for acquiring a thread identifier for each thread; a first determination unit for determining inactive threads in the allocated threads when the allocated thread group does not include a thread identifier and the allocated thread group is full; a first clearing unit for clearing inactive threads from the allocated thread group; and a first saving unit for allocating a corresponding target index for the thread identifier and saving the thread identifier in the allocated thread group.
[0129] In one embodiment, the first clearing unit is further configured to determine that the target index allocated to the inactive thread is invalid after clearing the inactive thread from the allocated thread group.
[0130] In one embodiment, the allocation module 410 further includes: an allocation unit, configured to allocate a corresponding target index to a thread identifier when the allocated thread group does not include a thread identifier and the allocated thread group is not full; and a second storage unit, configured to store the thread identifier in the allocated thread group.
[0131] In one embodiment, the allocation module 410 further includes at least one of the following: a first output unit, configured to determine that the target index corresponding to the thread identifier is invalid and output a first exception alarm when the thread identifier does not match the thread pool metadata; and a second output unit, configured to output a second exception alarm when the thread identifier is duplicated.
[0132] In one embodiment, the recording module 420 includes at least one of the following: a first recording unit, configured to record the thread information of the target thread at the associated position of the target index in the read lock holding object table when the target thread has been allocated a target index and the target index is valid; and a second recording unit, configured to allocate a target index to the target thread when the target thread has not been allocated a target index, and record the thread information of the target thread at the associated position of the target index in the read lock holding object table when the target index is valid.
[0133] In one embodiment, the clearing module 430 includes a second clearing unit, configured to clear the thread information of the target thread from the read lock holding object table when the target thread has been allocated a target index and the target index is valid.
[0134] The modules in the aforementioned read lock status determination device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0135] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a read lock state determination method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0136] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0137] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0138] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0139] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0140] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0141] In one embodiment, when the processor executes a computer program, it further performs the following steps: for each thread, obtains the thread identifier of the thread; if the thread identifier is not included in the allocated thread group and the allocated thread group is full, identifies inactive threads in the allocated thread group; removes inactive threads from the allocated thread group; allocates a corresponding target index for the thread identifier and stores the thread identifier in the allocated thread group.
[0142] In one embodiment, when the processor executes a computer program, it also performs the following steps: determining that the target index allocated to an inactive thread is invalid.
[0143] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the thread identifier is not included in the allocated thread group and the allocated thread group is not full, allocate a corresponding target index for the thread identifier; and store the thread identifier in the allocated thread group.
[0144] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the thread identifier does not match the thread pool metadata, it determines that the target index corresponding to the thread identifier is invalid and outputs a first exception alarm; if the thread identifier is duplicated, it outputs a second exception alarm.
[0145] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table; if the target thread has not been allocated a target index, allocate a target index for the target thread; if the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table.
[0146] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table.
[0147] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:
[0148] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0149] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0150] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0151] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: for each thread, obtains the thread identifier of the thread; if the thread identifier is not included in the allocated thread group and the allocated thread group is full, identifies the inactive thread in the allocated thread group; removes the inactive thread from the allocated thread group; assigns a corresponding target index to the thread identifier and stores the thread identifier in the allocated thread group.
[0152] In one embodiment, when the computer program is executed by the processor, it also performs the following steps: determining that the target index allocated to an inactive thread is invalid.
[0153] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the thread identifier is not included in the allocated thread group and the allocated thread group is not full, allocate a corresponding target index for the thread identifier; and store the thread identifier in the allocated thread group.
[0154] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the thread identifier does not match the thread pool metadata, determine that the target index corresponding to the thread identifier is invalid and output a first exception alarm; if the thread identifier is duplicated, output a second exception alarm.
[0155] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table; if the target thread has not been allocated a target index, allocate a target index for the target thread; if the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table.
[0156] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table.
[0157] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:
[0158] Allocate a target index for at least one thread; the target index is used to characterize the thread's associated position in the read lock holding object table;
[0159] If a target thread in at least one thread acquires a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread.
[0160] If the target thread releases the read lock, the target thread's thread information is removed from the read lock holding object table.
[0161] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: for each thread, obtains the thread identifier of the thread; if the thread identifier is not included in the allocated thread group and the allocated thread group is full, identifies the inactive thread in the allocated thread group; removes the inactive thread from the allocated thread group; assigns a corresponding target index to the thread identifier and stores the thread identifier in the allocated thread group.
[0162] In one embodiment, when the computer program is executed by the processor, it also performs the following steps: determining that the target index allocated to an inactive thread is invalid.
[0163] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the thread identifier is not included in the allocated thread group and the allocated thread group is not full, allocate a corresponding target index for the thread identifier; and store the thread identifier in the allocated thread group.
[0164] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the thread identifier does not match the thread pool metadata, determine that the target index corresponding to the thread identifier is invalid and output a first exception alarm; if the thread identifier is duplicated, output a second exception alarm.
[0165] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table; if the target thread has not been allocated a target index, allocate a target index for the target thread; if the target index is valid, record the thread information of the target thread at the associated position of the target index in the read lock holding object table.
[0166] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table.
[0167] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0168] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0169] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for determining the state of a read lock, characterized in that, The method includes: Assign a target index to at least one thread; the target index is used to characterize the associated position of the thread in the read lock holding object table; When a target thread in at least one of the threads adds a read lock, the thread information of the target thread is recorded in the read lock holding object table according to the target index of the target thread; If the target thread releases the read lock, the thread information of the target thread is removed from the read lock holding object table.
2. The method according to claim 1, characterized in that, The allocation of a target index for at least one thread includes: For each thread, obtain the thread identifier of that thread; If the thread identifier is not included in the allocated thread group and the allocated thread group is full, identify the inactive thread among the allocated threads; Remove the inactive thread from the assigned thread group; Assign a corresponding target index to the thread identifier and store the thread identifier in the assigned thread group.
3. The method according to claim 2, characterized in that, After removing the inactive thread from the allocated thread group, the method further includes: It was determined that the target index allocated to the inactive thread was invalid.
4. The method according to claim 2, characterized in that, The method further includes: If the thread identifier is not included in the allocated thread group, and the allocated thread group is not full, allocate a corresponding target index for the thread identifier; and, The thread identifier is stored in the assigned thread group.
5. The method according to claim 2, characterized in that, The method further includes at least one of the following: If the thread identifier does not match the thread pool metadata, determine that the target index corresponding to the thread identifier is invalid and output the first exception alarm; If the thread identifier is duplicated, output a second exception alarm.
6. The method according to any one of claims 1-5, characterized in that, The step of recording the thread information of the target thread in the read lock holding object table according to the target index of the target thread includes at least one of the following: If the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is recorded at the associated position of the target index in the read lock holding object table; If no target index has been allocated to the target thread, allocate a target index to the target thread. If the target index is valid, the thread information of the target thread is recorded at the associated position of the target index in the read lock holding object table.
7. The method according to any one of claims 1-5, characterized in that, The step of clearing the thread information of the target thread from the read lock holding object table includes: If the target thread has been allocated a target index and the target index is valid, the thread information of the target thread is cleared from the read lock holding object table.
8. A lock read status determination device, characterized in that, The device includes: An allocation module is used to allocate a target index to at least one thread; the target index is used to characterize the associated position of the thread in the read lock holding object table; A recording module is used to record the thread information of the target thread in the read lock holding object table according to the target index of the target thread when the target thread adds a read lock in the at least one thread. The clearing module is used to clear the thread information of the target thread from the read lock holding object table when the target thread releases the read lock.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.