Multi-threaded concurrent access method and apparatus

Abstract

Embodiments of the present application disclose a multi-threaded concurrent access method, used for improving the efficiency of concurrent access of multiple threads to shared resources. The method in the embodiments of the present application comprises: a computing device receives a first locking request, wherein the first locking request is used for requesting a mutual trust lock for a first thread to perform a write operation on a shared resource, and the mutual trust lock is used for performing a non-exclusive write operation on the shared resource; the computing device issues the mutual trust lock to the first thread on the basis of the first locking request; and the first thread and a second thread concurrently perform a write operation on the shared resource on the basis of the mutual trust lock, wherein the second thread is a thread having obtained the mutual trust lock.

Description

Multi-threaded concurrent access method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on June 25, 2023, with application number 202310757395.9 and invention name “A multi-threaded concurrent access method and device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of computers, and in particular to a multi-threaded concurrent access method and device. Background Art

[0003] Read-write locks are a common synchronization mechanism in multithreaded programming. They employ specific algorithms and data structures to balance security and efficiency in read and write operations on shared resources. When multiple threads access the same shared resource, read-write locks are used to control access to the resource to prevent conflicts.

[0004] Currently, locks have two states: write lock and read lock. The write lock is an exclusive lock, which allows only one thread to read or write to a shared resource. Once in the write lock state, other threads cannot hold the write lock or the read lock. The read lock is a shared lock, which allows multiple threads to hold the read lock simultaneously and read data.

[0005] Currently, multithreaded access to shared resources utilizes read-write locks. In large-scale concurrency scenarios, shared resources are processed serially by multiple threads. When the scope of the protected shared resource is large, different threads may have different access scopes. For example, when locking a large structure or array, to ensure resource consistency, a write lock is applied to the entire shared resource, regardless of whether a thread accesses a single field or array element, or modifies multiple fields or array elements. This results in inefficient concurrent access to shared resources.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a thread concurrent access method and apparatus for improving the efficiency of multi-threaded concurrent access to shared resources.

[0008] The first aspect of the embodiment of the present application provides a multi-threaded concurrent access method, which can be executed by a computing device, or by a component of the computing device, such as a processor, chip, or chip system of the computing device, or by a logic module or software that can implement all or part of the computing device functions. Taking the execution of the computing device as an example, the method of the first aspect includes: the computing device receives a first lock request, the first lock request is used to request a mutual trust lock for a first thread to perform a write operation on a shared resource, and the mutual trust lock is used to perform a non-exclusive write operation on the shared resource. The computing device is used to execute a first thread and a second thread, the first thread is used to perform a write operation on a first data unit of the shared resource, and the second thread is used to perform a write operation on a second data unit of the shared resource, and the first data unit and the second data unit are different data units. The computing device issues a mutual trust lock to the first thread according to the first lock request. After the first thread obtains the mutual trust lock, the first thread and the second thread concurrently perform write operations on the shared resource based on the mutual trust lock, and the second thread is the thread that has obtained the mutual trust lock.

[0009] An embodiment of the present application provides a mutual trust lock state, which enables multiple threads in a computing device to concurrently perform write operations on different data units of a shared resource through a mutual trust lock, thereby eliminating conflict waiting in the write lock state and improving the efficiency of multi-threaded access to shared resources of the computing device.

[0010] In one possible implementation, the computing device is further configured to execute a third thread, the third thread being configured to perform a write operation on a global data unit of a shared resource. The computing device receives a second lock request, the second lock request being configured to request a mutual trust lock for the third thread to perform a concurrent write operation on the shared resource. After the first thread or the second thread acquires the mutual trust lock, the third thread waits for the mutual trust lock to be released.

[0011] In the embodiment of the present application, the computing device can issue mutual trust locks to threads accessing different data units of shared resources. Threads accessing data units of shared resources with conflicts cannot obtain the mutual trust lock, thereby improving the efficiency of mutual trust threads' write operations on shared resources while ensuring the security of write operations on shared resources.

[0012] In one possible implementation, during the process of issuing a mutual trust lock to a first thread in response to a first lock request, when the mutual trust lock status bit of a lock state variable is not set, the computing device sets the mutual trust lock status bit of the lock state variable in response to the first lock request and increments the lock count bit of the lock state variable. When the mutual trust lock status bit of the lock state variable is set, the computing device increments the lock count bit of the lock state variable in response to the first lock request.

[0013] In the embodiment of the present application, the computing device records the mutual trust lock status corresponding to the shared resource by adding a mutual trust lock status bit in the lock status variable, and records the number of threads holding the mutual trust lock through the mutual trust lock status bit and the lock count bit. The computing device can also increase the lock count bit according to the lock request, thereby improving the feasibility of multi-threaded concurrent access to shared resources.

[0014] In one possible implementation, a computing device receives a first unlock request from a first thread, the first unlock request being used to request the release of a mutual trust lock on a shared resource. When a lock count bit of a lock state variable is greater than 1, the lock count bit of the lock state variable is decremented according to the first mutual trust lock unlock request. When the lock count bit of the lock state variable is equal to 1, the lock count bit of the lock state variable is decremented according to the first mutual trust lock unlock request, and the mutual trust lock state bit of the lock state variable is restored to unset.

[0015] In the embodiment of the present application, the computing device can decrement the lock count bit according to the unlock request. When the lock count bit is decremented to 0, the computing device restores the mutual trust lock status bit to the set position, thereby improving the feasibility of multi-threaded concurrent access to shared resources.

[0016] In one possible implementation, the computing device is also used to execute a fourth thread, which is a thread that already holds a mutual trust lock. The fourth thread is used to perform a write operation on the first data unit of the shared resource. The computing device receives a third lock request, which is used to request a segmented lock for the fourth thread to perform a write operation on the first data unit of the shared resource. The segmented lock is used to exclusively access the first data unit.

[0017] In an embodiment of the present application, the computing device can issue segmented locks to threads holding mutual trust locks, so that while multiple threads concurrently perform write operations on shared resources, the threads can perform exclusive write operations on a certain data unit of the shared resources, thereby improving the efficiency of multi-threaded write operations on shared resources and the security of multi-threaded write operations on shared resources.

[0018] In one possible implementation, when the first thread holds the mutual trust lock, other threads cannot hold the write lock or read lock corresponding to the shared resource. The write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource. When the first thread holds the write lock, other threads cannot hold the mutual trust lock or read lock corresponding to the shared resource. When the first thread holds the read lock, other threads cannot hold the mutual trust lock or write lock corresponding to the shared resource.

[0019] In the embodiment of the present application, different lock states corresponding to shared resources cannot appear at the same time, thereby improving the protection capabilities of different lock states.

[0020] In one possible implementation, when the mutual trust lock status bit is not set, the lock count bit is used to indicate the number of threads holding the read lock.

[0021] In the embodiment of the present application, the computing device adds a mutual trust lock status bit and uses the lock count bit to record the number of threads holding the write lock, thereby reusing the lock count bit of the read lock and improving the recording efficiency of the lock count bit.

[0022] In one possible implementation, mutual trust locks are applied to database transaction management. Multiple threads of a computing device concurrently write to the transaction state in the database based on the mutual trust lock. Transaction states include active, committed, and rollback. A transaction in the interactive state is not yet complete, and database operations can continue. In the committed state, the transaction's modifications have been successfully submitted to the database, making all changes permanent. In the rollback state, the transaction has been rolled back, canceled, or failed, undoing all operations and changes, and restoring the modified data to the state before the transaction began.

[0023] In the embodiment of the present application, the computing device can concurrently write the transaction status in the database through the mutual trust lock, thereby improving the concurrent writing performance of the transaction status.

[0024] In one possible implementation, mutual trust locks are used for database page management. Database page management involves dividing a database's data files into fixed-size data blocks, known as pages. The computing device manages the use and status of these pages, including page reads and writes. Multiple threads of the computing device concurrently write to entries in the database pages based on the mutual trust lock.

[0025] In the embodiment of the present application, the computing device can concurrently write to the database pages through mutual trust locks, lock a single database page and modify the locks of different areas of the database page, thereby improving the concurrent write performance of transactions in the database pages.

[0026] A second aspect of an embodiment of the present application provides a multi-threaded concurrent access device, the device being used to execute a first thread and a second thread, the first thread being used to perform a write operation on a first data unit of a shared resource, the second thread being used to perform a write operation on a second data unit of the shared resource, the first data unit and the second data unit being different data units, the device comprising a transceiver unit and a processing unit, wherein the transceiver unit is used to receive a first lock request, the first lock request being used to request a mutual trust lock for the first thread to perform a write operation on the shared resource, the mutual trust lock being used to perform a non-exclusive write operation on the shared resource. The processing unit is used to issue a mutual trust lock to the first thread based on the first lock request, the first thread and the second thread of the processing unit concurrently perform write operations on the shared resource based on the mutual trust lock, and the second thread is the thread that has acquired the mutual trust lock.

[0027] In one possible embodiment, the apparatus is further configured to execute a third thread, the third thread being configured to perform a write operation on a shared resource global data unit, and the transceiver unit is further configured to receive a second lock request, the second lock request being configured to request a mutual trust lock for the third thread to perform a concurrent write operation on the shared resource. When the first thread or the second thread acquires the mutual trust lock, the third thread of the processing unit waits for the mutual trust lock to be released.

[0028] In one possible implementation, the processing unit is specifically configured to, when the mutual trust lock status bit of the lock state variable is not set, set the mutual trust lock status bit of the lock state variable according to the first lock request, and increment the lock count bit of the lock state variable. When the mutual trust lock status bit of the lock state variable is set, increment the lock count bit of the lock state variable according to the first lock request.

[0029] In one possible embodiment, the transceiver unit is further configured to receive a first unlock request from a first thread, the first unlock request being configured to request the release of a mutual trust lock on a shared resource. When the lock count bit of the lock state variable is greater than 1, the processing unit is configured to decrement the lock count bit of the lock state variable according to the first mutual trust lock unlock request. When the lock count bit of the lock state variable is equal to 1, the processing unit is configured to decrement the lock count bit of the lock state variable according to the first mutual trust lock unlock request, and restore the mutual trust lock state bit of the lock state variable to unset.

[0030] In one possible implementation, the device is also used to execute a fourth thread, which is a thread that already holds a mutual trust lock. The fourth thread is used to perform a write operation on the first data unit of the shared resource. The transceiver unit is also used to receive a third lock request, which is used to request the fourth thread to obtain a segmented lock for performing a write operation on the first data unit of the shared resource. The segmented lock is used to exclusively access the first data unit.

[0031] In one possible implementation, the processing unit is also used to prevent other threads from holding the write lock and read lock corresponding to the shared resource when the first thread holds the mutual trust lock. The write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource.

[0032] In one possible implementation, a mutual trust lock is applied to database transaction management, and multiple different threads concurrently write transaction states in the database based on the mutual trust lock.

[0033] In one possible implementation, a mutual trust lock is applied to database page management, and multiple different threads concurrently perform write operations on table entries in the database page based on the mutual trust lock.

[0034] A third aspect of an embodiment of the present application provides a computing device, including a processor, which is coupled to a memory, and the processor is used to store instructions. When the instructions are executed by the processor, the computing device executes the method described in the first aspect or any possible implementation method of the first aspect.

[0035] A fourth aspect of an embodiment of the present application provides a computing device cluster, comprising one or more computing devices, wherein the computing device includes a processor coupled to a memory, and the processor is used to store instructions. When the instructions are executed by the processor, the computing device cluster executes the method described in the first aspect or any possible implementation method of the first aspect.

[0036] A fifth aspect of the embodiments of the present application provides a computer-readable storage medium having instructions stored thereon. When the instructions are executed, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0037] A sixth aspect of the embodiments of the present application provides a computer program product, which includes instructions, and is characterized in that when the instructions are executed, the computer implements the method described in the first aspect or any possible implementation method of the first aspect.

[0038] It can be understood that the beneficial effects that can be achieved by any of the multi-threaded concurrent access devices, computing devices, computer-readable media or computer program products provided above can refer to the beneficial effects in the corresponding computing system and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] FIG1 is a schematic diagram of a thread concurrent access system architecture provided by an embodiment of the present application;

[0040] FIG2 is a flow chart of a method for concurrent thread access according to an embodiment of the present application;

[0041] FIG3 is a schematic diagram of different lock states provided by an embodiment of the present application;

[0042] FIG4 is a schematic diagram of another locking state provided by an embodiment of the present application;

[0043] FIG5 is a schematic diagram of a lock state variable provided in an embodiment of the present application;

[0044] FIG6a is a schematic diagram of a process for applying for a mutual trust lock according to an embodiment of the present application;

[0045] FIG6 b is a schematic diagram of a process of releasing a mutual trust lock according to an embodiment of the present application;

[0046] FIG7 is a schematic diagram of accessing a shared resource based on a segmented lock according to an embodiment of the present application;

[0047] FIG8a is a schematic diagram showing a comparison of system concurrency provided in an embodiment of the present application;

[0048] FIG8b is a schematic diagram showing another comparison of system concurrency provided in an embodiment of the present application;

[0049] FIG9 is a schematic diagram of a thread concurrency device provided in an embodiment of the present application;

[0050] FIG10 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0051] FIG11 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0052] FIG12 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] The embodiments of the present application provide a multi-threaded concurrent access method and device for improving the efficiency of multi-threaded concurrent access.

[0054] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0055] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0056] First, some terms involved in the embodiments of the present application are introduced to facilitate technical personnel in this field to understand the solution.

[0057] A read-write lock is a concurrency control mechanism used to optimize contention for read and write operations. A read-write lock consists of two mutually exclusive locks: a read lock and a write lock. Multiple read locks can be acquired simultaneously as long as no write lock is acquired. When a write lock is acquired, all threads reading and writing are blocked until the write lock is released. While a thread acquires the write lock, other threads cannot acquire either the read or write locks. Conversely, while a thread acquires the read lock, other threads can only acquire the read lock, not the write lock.

[0058] An atomic operation is an operation that can be completed in a single, indivisible step. In computer science, an atomic operation typically refers to an operation in a multithreaded environment that must either succeed in its entirety or fail in its entirety; it cannot complete partially. Atomic operations ensure data synchronization and consistency within a multi-threaded computer system. Operations include reads, writes, compares, and swaps. When using atomic operations, each operation is atomic.

[0059] Segmented locking is a method of using locks. Computing devices divide shared resources into multiple segments. Each segment has an independent lock to control concurrent access, narrowing the scope of concurrent access, reducing lock contention, and improving concurrent performance.

[0060] The following describes the multi-threaded concurrent access method and device provided by the embodiments of the present application in conjunction with the accompanying drawings.

[0061] Please refer to Figure 1, which is a schematic diagram of a system architecture for concurrent thread access according to an embodiment of the present application. In the example shown in Figure 1, computing device system 100 includes a processor 101 and memory 102. Processor 101 runs multiple threads, and memory 102 stores shared resources. Multiple threads in processor 101 can access the shared resources in memory 102. The following describes the specific functions of each component of computing device system 100.

[0062] Processor 101 executes computing tasks on a computing device. When executing a computing task, processor 101 may break the task into multiple threads for execution. Processor 101 can control the time slices of different threads to ensure that each thread is executed. For example, in the example shown in Figure 1, processor 101 can schedule thread 1, thread 2, and thread n to access different data units of a shared resource.

[0063] Processor 101 is also used to control the access mechanism for multiple threads to access shared data. Processor 101 can control the lock state corresponding to the shared resource. The lock states corresponding to the shared resource include a write lock state, a read lock state, and a mutual trust lock state. The write lock state only allows one thread to write to the shared resource. The read lock state allows multiple threads to read the shared resource. The mutual trust lock state is used for multiple mutually trusting threads to concurrently write to the shared resource. Mutually trusting threads refer to threads that will not access the same data unit of the shared resource at the same time.

[0064] Memory 102 is used to store shared resources of the computing device. Shared resources include data generated by processor 101 during the execution of computing tasks. Processor 101 can access the shared resources stored in memory 102. For example, in the example shown in Figure 1, processor 101 can read data from the first data unit of the shared resource in memory 102 by executing thread 1, or processor 101 can write data to the second data unit of the shared resource in memory 102 by executing thread 2, or processor 101 can access all data units of the shared resource in memory 102 by executing thread 5.

[0065] Please refer to Figure 2, which is a flowchart of a multi-threaded concurrent access provided by an embodiment of the present application. In the example shown in Figure 2, the multi-threaded concurrent access provided by the embodiment of the present application includes the following steps:

[0066] 201. A computing device receives a first lock request, where the first lock request is used to request a mutual trust lock for a first thread to perform a write operation on a shared resource, where the mutual trust lock is used to perform a non-exclusive write operation on the shared resource.

[0067] When a computing device executes a computing task, it accesses shared memory resources by executing multiple threads. To avoid access conflicts, only threads holding locks can access shared resources. For example, a thread holding a write lock can perform exclusive write operations on a shared resource, while multiple threads holding a read lock can concurrently read from the shared resource.

[0068] The embodiment of the present application also provides a lock state, namely a mutual trust lock, whereby multiple threads holding the mutual trust lock in a computing device can concurrently write to a shared resource. The mutual trust lock state provided by the embodiment of the present application is described below in conjunction with the first thread and the second thread.

[0069] The computing device receives a first lock request, which is used to request a mutual trust lock for a first thread to perform a write operation on a shared resource. The mutual trust lock is used to perform non-exclusive write operations on the shared resource, that is, multiple threads holding the mutual trust lock can concurrently write to the shared resource. The computing device can issue mutual trust locks to multiple mutually trusting threads, which are threads that do not access the same data unit of the shared resource at the same time. For example, a first thread performs a write operation on a first data unit of a shared resource, and a second thread performs a write operation on a second data unit of the shared resource. The first data unit and the second data unit are different data units, and the first thread and the second thread are mutually trusting threads.

[0070] Please refer to Figure 3, which is a schematic diagram of different lock states provided in an embodiment of the present application. In the example shown in Figure 3, the lock states include a write lock state, a read lock state, and a mutual trust lock state. In the write lock state, the locked threads can exclusively read and write to the shared resource. In the read lock state, the locked threads can concurrently read the shared resource. In the mutual trust lock state, the locked threads can concurrently read and write to the shared resource.

[0071] For example, in the example shown in Figure 3, after thread 1 acquires the write lock, thread 1 writes to the global data of the shared resource. Threads 2 and 3 are unable to write to the global array of the shared resource and wait for thread 1 to write. Thread 1 then exclusively writes to the global data of the shared resource. After thread 1 releases the write lock, thread 2 acquires the write lock and exclusively writes to the global data of the shared resource.

[0072] For another example, in the example shown in Figure 3, thread 1, thread 2 and thread 3 can obtain read locks at the same time, and thread 1 concurrently performs read operations on the global data of shared resources, where thread 1 performs a read operation on data unit 1 of the global array, thread 2 performs a read operation on data unit 3 of the global array, and thread 3 performs a read operation on data unit 5 of the global array.

[0073] In the example shown in Figure 3, when thread 1, thread 2 and thread n respectively access different data units of global data, thread 1, thread 2 and thread 3 can request a mutual trust lock from the computing device. After thread 1, thread 2 and thread n obtain the mutual trust lock, thread 1, thread 2 and thread 3 can concurrently access the global array of shared resources. For example, thread 1 writes to data unit 1 of the global array, while thread 2 writes to data unit 2 of the global array, and while thread 3 writes to data unit 5 of the global array.

[0074] In one possible implementation, when the first thread holds the mutual trust lock, other threads cannot hold the write lock and read lock corresponding to the shared resource. The write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource.

[0075] In the embodiments of the present application, different lock states cannot occur simultaneously. A write lock can only be held by one thread at a time. When the lock is in the write lock state, other threads cannot hold the read lock or the mutual trust lock. A read lock can be held by multiple threads simultaneously. When the lock is in the read lock state, other threads cannot hold the write lock or the mutual trust lock. A mutual trust lock can be held by multiple threads simultaneously. When the lock is in the mutual trust lock state, other threads cannot hold the write lock or the read lock.

[0076] Please refer to Figure 4, which is a schematic diagram of the relationship between different lock states provided in an embodiment of the present application. In the example shown in Figure 4, when a thread holds a write lock, other threads cannot hold the write lock, read lock, or mutual trust lock. When a thread holds a read lock, other threads cannot hold the write lock and mutual trust lock. When a thread holds the mutual trust lock, other threads cannot hold the write lock and read lock.

[0077] For example, in the example shown in Figure 4, when thread 1 is in the write lock state, threads 2 through 7 cannot acquire the write lock, read lock, and mutual trust lock. Threads 2 through 7 wait for thread 1 to release the write lock. After thread 1 releases the write lock, thread 2 acquires the write lock, and threads 1, 3, 3, and 7 cannot acquire the write lock, read lock, and mutual trust lock. After thread 2 releases the write lock, threads 3 and 4 acquire the read lock. Threads 3 and 4 can perform concurrent read operations on the shared resource. At this time, threads 1, 2, and 5 through 7 cannot acquire the write lock and mutual trust lock.

[0078] In the example shown in Figure 4, when thread 5 is in the mutual trust lock state, threads 1 to 6 and threads 5 to 7 cannot obtain write locks and read locks, but threads 6 to 7 can obtain the mutual trust lock. Since threads 5 to 7 are mutually trusted threads, after threads 5 to 7 obtain the mutual trust lock, they can concurrently perform write operations on different data units of the shared resource.

[0079] In one possible implementation, a computing device receives a second lock request, the second lock request being used to request a mutual trust lock for a third thread to perform a concurrent write operation on a shared resource, where the third thread is performing a write operation on a global data unit of the shared resource. Because the first and third threads' write operations on the shared resource conflict, the first and third threads are not mutually trusted. Therefore, after the first or second thread acquires the mutual trust lock, the third thread cannot acquire the mutual trust lock and must wait for the mutual trust lock to be released.

[0080] Please continue to refer to Figure 3. In the example shown in Figure 3, because threads 1, 2, and 3 access different data units of global data, threads 1, 2, and 3 can simultaneously hold the mutual trust lock corresponding to the shared resource. When thread m needs to access the global array, thread m does not mutually trust threads 1, 2, and n respectively. Therefore, thread m cannot obtain the mutual trust lock.

[0081] In one possible implementation, the computing device receives a write lock application request, and reads the lock status variable to determine whether it is already in a read lock state, a write lock state, or a mutual trust lock state. If it is already locked, then the write lock application fails and a new application is made. During this period, it can be retried immediately or it can wait to be awakened by other release processes. If it is not locked, then the variable write lock status bit needs to be set, and the variable is atomically operated. If the modification is successful, the write lock is successfully added. If the modification fails, it means that another task has first locked and modified the variable value during this period, then the lock fails and enters the retry, wait, or other processes.

[0082] In one possible implementation, a computing device receives a read lock request and first reads the lock state variable to determine whether it is already in a write lock or mutual trust lock state. If it is already in a write lock or mutual trust lock state, the read lock request fails and a new request is made. The request can be retried immediately or by waiting to be awakened by another release process. If it is not in a write lock or mutual trust lock state, the read lock count bit of the variable is incremented by 1, and an atomic operation is performed on the lock state variable. If the modification is successful, the read lock is successfully added. If the modification fails, it means that another task has modified the variable value during this period, the lock fails, and a retry or other process is entered.

[0083] 202. The computing device issues a mutual trust lock to the first thread according to the first lock request.

[0084] The computing device issues a mutual trust lock to the first thread according to the first locking request. Specifically, the computing device modifies the lock state variable corresponding to the shared resource according to the first locking request. The lock state variable in the embodiment of the present application includes a write lock status bit, a mutual trust lock status bit and a lock count bit, wherein the write lock status bit is used to indicate whether the lock is in a write lock state, the mutual trust lock state is used to indicate whether the lock is in a mutual trust lock state, and the lock count bit is used to indicate the number of threads holding a read lock or the number of threads holding a mutual trust lock. Specifically, when the mutual trust lock status bit is not set, the lock count bit is used to indicate the number of threads holding a read lock, and when the mutual trust lock status bit is set, the lock count bit is used to indicate the number of threads holding a mutual trust lock.

[0085] Please refer to Figure 5, which is a schematic diagram of a lock state variable provided by the implementation of this application. In the example shown in Figure 5, the first bit of the lock state variable is the write lock state bit. When the write lock state bit is not set, there is no thread in the write lock state. When the write lock state bit is set, there is a thread in the write lock state, and the thread holding the write lock can read the data. The second bit of the lock state variable is the mutual trust lock state bit. When the mutual trust lock state bit is not set, the lock count bit is the count of threads holding the read lock. When the mutual trust lock state bit is set, there is at least one thread in the mutual trust lock state, and the lock count bit is the count of threads holding the mutual trust lock.

[0086] In the example shown in Figure 5, the write lock status bit of the lock state variable is 0, the mutual trust lock status bit is 1, and the lock count bit is 11 (binary). Then, the computing device has three threads in the mutual trust lock state, and the three threads in the mutual trust lock state can concurrently perform write operations on different data units of the shared resource.

[0087] In one possible implementation, when the mutual trust lock state bit of the lock state variable is not set, the computing device sets the mutual trust lock state bit of the lock state variable according to the first lock request and increments the lock count bit of the lock state variable. When the mutual trust lock state bit of the lock state variable is set, the computing device increments the lock count bit of the lock state variable according to the first lock request.

[0088] Please refer to Figure 6a, which is a schematic diagram of a process for applying for a mutual trust lock provided by an embodiment of the present application. In the example shown in Figure 6a, after the computing device thread requests to apply for a mutual trust lock, the computing device queries the current lock state. When the lock state is in a read lock state or a write lock state, the computing device thread waits to acquire the mutual trust lock. When the lock state is in an unlocked state or a mutual trust lock state, the computing device thread can acquire the mutual trust lock. After the computing device thread acquires the mutual trust lock, the computing device sets the mutual trust lock state bit of the lock state variable and increments the lock count bit.

[0089] Please continue to refer to Figure 5. In the example shown in Figure 5, the write lock state of the lock state variable is 0, the mutual trust lock state bit is 1, and the lock count bit is 11 (binary). When a thread applies for a mutual trust lock, there are 3 threads holding the mutual trust lock. The computing device adds 1 to the lock count bit of the lock state variable according to the lock request. The modified lock count bit is 100 (binary), that is, the number of threads holding the mutual trust lock is 4.

[0090] In one possible implementation, a computing device receives a first unlock request from a first thread, the first unlock request being used to request the release of a mutual trust lock on a shared resource. When a lock count bit of a lock state variable is greater than 1, the lock count bit of the lock state variable is decremented according to the first mutual trust lock unlock request. When the lock count bit of the lock state variable is equal to 1, the lock count bit of the lock state variable is decremented according to the first mutual trust lock unlock request, and the mutual trust lock state bit of the lock state variable is restored to unset.

[0091] Please refer to Figure 6b, which is a schematic diagram of a process for releasing a mutual trust lock provided by an embodiment of the present application. In the example shown in Figure 6b, after a thread of a computing device requests to release the mutual trust lock, the computing device queries the current lock state and decrements the lock count bit of the lock state variable. When the lock count bit of the lock state variable is 1, the computing device decrements the lock count bit of the lock state variable and then resets the mutual trust lock state bit. After the interlock lock state is reset, the mutual trust lock is released.

[0092] Please continue to refer to Figure 5. In the example shown in Figure 5, the write lock state of the lock state variable is 0, the mutual trust lock state bit is 1, and the lock count bit is 11 (binary). When a thread applies to release the mutual trust lock, there are 3 threads holding the mutual trust lock. The computing device subtracts 1 from the lock count bit of the lock state variable according to the unlock request. The modified lock count bit is 10 (binary), that is, the number of threads holding the mutual trust lock is 4.

[0093] In one possible implementation, the computing device is further configured to execute a fourth thread, which already holds a mutual trust lock and is configured to perform a write operation on a first data unit of a shared resource. The computing device receives a third lock request, which requests a segment lock for the fourth thread to perform the write operation on the first data unit of the shared resource. The segment lock is configured to grant exclusive access to the first data unit. While the fourth thread holds the segment lock, the fourth thread has exclusive access to the first data unit of the shared resource.

[0094] In embodiments of the present application, when threads holding a mutual trust lock need to access the same data unit of a shared resource, the computing device can use a segmentation lock to control the threads holding the mutual trust lock to serially access the same data unit of the shared resource. For example, if a first thread holding a mutual trust lock and a fourth thread holding a mutual trust lock both need to access a first data unit of a shared resource, the computing device can use a segmentation lock to control the first thread and a second hyperthread to serially access the first data unit.

[0095] Please refer to Figure 7, which is a schematic diagram of a segmented lock-based access to shared resources provided by an embodiment of the present application. In the example shown in Figure 7, thread 1 and thread 2 are threads holding mutual trust locks. Thread 1 and thread 2 can concurrently access different data units in the global array. When thread 1 and thread 2 concurrently access data unit 3, the computing device controls thread 1 and thread 2 to serially access data unit 3 through the segmented lock. When thread 1 holds the segmented lock corresponding to data unit 3, thread 1 can write to data unit 3. After thread 1 releases the segmented lock corresponding to data unit 3, thread 2 can obtain the segmented lock corresponding to data unit 3 and perform an exclusive write operation on data unit 3.

[0096] Similarly, in the example shown in Figure 7, thread m and thread n are also threads holding mutual trust locks. The computing device controls thread m and thread n to serially access data unit 7 through segment locks. When thread m holds the segment lock corresponding to data unit 7, thread m can write to data unit 7. After thread n releases the segment lock corresponding to data unit 7, thread n can obtain the segment lock corresponding to data unit 7 and perform exclusive write operations on data unit 7.

[0097] In the example shown in Figure 7, the computing device can issue segment locks to thread n and thread m that hold mutual trust locks, so that while thread n and thread m concurrently write to shared resources, thread n and thread m can perform exclusive write operations on the data unit 7 segment of the shared resource, thereby improving the security of multi-threaded write operations on shared resources.

[0098] In the implementation of this application, computing devices can add a finer-grained sub-lock, namely a segmented lock, based on the mutual trust lock. The computing device can modify different data units within a shared resource through the mutual trust lock, while the segmented lock protects the same data unit within the shared resource, ensuring that only serial modifications can be made. This improves the security of multi-threaded write operations on the same data unit of the shared resource.

[0099] 203. The first thread and the second thread concurrently perform a write operation on a shared resource based on a mutual trust lock, where the second thread is the thread that holds the mutual trust lock.

[0100] After the first thread acquires the mutual trust lock, the first thread and the second thread concurrently write to the shared resource, and the second thread is the thread that has acquired the mutual trust lock. It should be noted that the number of the first thread and the second thread in the embodiment of the present application is not limited.

[0101] In one possible implementation, mutual trust locks are applied to database transaction management. Multiple threads of a computing device concurrently write to the transaction state in the database based on the mutual trust lock. Transaction states include active, committed, and rollback. A transaction in the interactive state is not yet complete, and database operations can continue. In the committed state, transaction modifications have been successfully submitted to the database, making all changes permanent. In the rollback state, a transaction has been rolled back, canceled, or failed, undoing all operations and changes, and restoring the modified data to the state before the transaction began.

[0102] For example, in the openGauss database, computing devices need to update the transaction status when a transaction is committed. The transaction status is an array. The computing device manages the transaction status data globally and periodically performs snapshot scans of the transaction status array. Therefore, the computing device needs to lock the entire array so that the computing device's threads can only access or modify one transaction array cell at a time. The computing device improves the concurrency of transaction status write operations by changing the thread's read and write locks to mutual trust locks.

[0103] Please refer to Figure 8a, which is a schematic diagram of an embodiment of the present application providing a method of using a mutual trust lock to improve the concurrency of a computing device. In the coordinate system shown in Figure 8a, the horizontal axis is the number of concurrency and the vertical axis is the number of transactions per second (TPS) of the computing device. The computing device can optimize the transaction update (update) operation of the database using the mutual trust lock. From the example shown in Figure 8a, it can be seen that after the computing device optimizes the transaction update operation using the mutual trust lock, the TPS of the transaction update operation is increased from 100,000 per second to 490,000 per second, an increase of 5 times.

[0104] Please refer to Figure 8b, which is a schematic diagram of an embodiment of the present application, providing an example of using mutual trust locks to improve the concurrency capabilities of a computing device. In the example shown in Figure 8b, the computing device can optimize the transaction insert operation of the database by using mutual trust locks. As can be seen from the example shown in Figure 8b, after the computing device optimizes the transaction insert operation by using mutual trust locks, the TPS of the computing device for the transaction insert operation increases from 100,000 per second to 500,000 per second, a 5-fold increase.

[0105] In one possible implementation, mutual trust locks are applied to database page management. Database page management refers to dividing the database data file into a set of fixed-size pages. The computing device manages the use and status of these pages, including reading and writing pages. Multiple different threads of the computing device concurrently write to table entries in the database based on mutual trust locks.

[0106] For example, in a MySQL-based database, when a computing device needs to write to multiple table items in a database page, multiple threads of the computing device can concurrently write to different table items in the database page through mutual trust locks, thereby improving the computing device's management efficiency of data pages.

[0107] It should be noted that the mutual trust lock provided in the embodiments of the present application is not limited to specific products. Software such as operating systems and databases can implement and use mutual trust locks. When application software, middleware, and underlying software need to use mutual trust locks, they can call the mutual trust lock library function interface provided in the operating system, or they can directly implement the mutual trust lock function in their own software. There is no specific limitation.

[0108] It can be seen from the above embodiments that the embodiments of the present application provide that multiple threads in a computing device concurrently write to different data units of a shared resource through a mutual trust lock, thereby improving the efficiency of multi-threaded access to shared resources of the computing device.

[0109] The above describes the multi-threaded concurrent access method provided by the embodiment of the present application. The following describes the multi-threaded concurrent access device provided by the embodiment of the present application.

[0110] Please refer to Figure 9, which is a schematic diagram of the structure of a multi-threaded concurrent access device provided in an embodiment of the present application. In the example shown in Figure 9, the multi-threaded concurrent access device is used to implement the various steps performed by the computing device in the above embodiments. The multi-threaded concurrent access device 900 includes a transceiver unit 901 and a processing unit 902.

[0111] Among them, the transceiver unit 901 is used to receive a first lock request, and the first lock request is used to request a mutual trust lock for the first thread to perform a write operation on a shared resource. The mutual trust lock is used to perform a non-exclusive write operation on the shared resource. The processing unit 902 is used to issue a mutual trust lock to the first thread according to the first lock request. The first thread and the second thread of the processing unit 902 concurrently perform write operations on the shared resource based on the mutual trust lock. The second thread is the thread that has obtained the mutual trust lock. The first thread is used to write to the first data unit of the shared resource, and the second thread is used to write to the second data unit of the shared resource. The first data unit and the second data unit are different data units.

[0112] In one possible embodiment, the apparatus is further configured to execute a third thread, the third thread being configured to perform a write operation on a shared resource global data unit, and the transceiver unit 901 is further configured to receive a second lock request, the second lock request being configured to request a mutual trust lock for a concurrent write operation on the shared resource by the third thread. After the first thread or the second thread acquires the mutual trust lock, the third thread of the processing unit 902 waits for the mutual trust lock to be released.

[0113] In one possible implementation, the processing unit 902 is specifically configured to, when the mutual trust lock status bit of the lock state variable is not set, set the mutual trust lock status bit of the lock state variable according to the first lock request, and increment the lock count bit of the lock state variable. When the mutual trust lock status bit of the lock state variable is set, increment the lock count bit of the lock state variable according to the first lock request.

[0114] In one possible embodiment, the transceiver unit 901 is further configured to receive a first unlock request from the first thread, the first unlock request being used to request the release of the mutual trust lock of the shared resource. When the lock count bit of the lock state variable is greater than 1, the processing unit 902 is specifically configured to decrement the lock count bit of the lock state variable according to the first mutual trust lock unlock request. When the lock count bit of the lock state variable is equal to 1, the processing unit 902 is specifically configured to decrement the lock count bit of the lock state variable according to the first mutual trust lock unlock request, and restore the mutual trust lock state bit of the lock state variable to unset.

[0115] In one possible implementation, the device is also used to execute a fourth thread, which is a thread that already holds a mutual trust lock. The fourth thread is used to perform a write operation on the first data unit of the shared resource. The transceiver unit 901 is also used to receive a third lock request. The third lock request is used to request the fourth thread to obtain a segmented lock for performing a write operation on the first data unit of the shared resource. The segmented lock is used to exclusively access the first data unit.

[0116] In one possible implementation, the processing unit 902 is also used to prevent other threads from holding the write lock and read lock corresponding to the shared resource when the first thread holds the mutual trust lock. The write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource.

[0117] In one possible implementation, a mutual trust lock is applied to database transaction management, and multiple different threads concurrently write transaction states in the database based on the mutual trust lock.

[0118] In one possible implementation, a mutual trust lock is applied to database page management, and multiple different threads concurrently perform write operations on table entries in the database page based on the mutual trust lock.

[0119] It should be understood that the division of units in the above device is merely a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. Moreover, the units in the device can all be implemented in the form of software called through processing elements; or they can all be implemented in the form of hardware; or some units can be implemented in the form of software called through processing elements, and some units can be implemented in the form of hardware. For example, each unit can be a separately established processing element, or it can be integrated into a certain chip of the device. In addition, it can also be stored in the memory in the form of a program, called by a certain processing element of the device and perform the function of the unit. In addition, all or part of these units can be integrated together, or they can be implemented independently. The processing element described here can also be a processor, which can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each unit above can be implemented by the integrated logic circuit of the hardware in the processor element or in the form of software called through the processing element.

[0120] It is worth noting that, for the sake of simplicity, the above method embodiments are expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited to the order of the actions described. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required for the present invention.

[0121] Other reasonable step combinations that can be thought of by those skilled in the art based on the above description also fall within the scope of protection of the present invention. Secondly, those skilled in the art should also be familiar with that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the present invention.

[0122] Please refer to Figure 10, which is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. As shown in Figure 10, the computing device 1000 includes: a processor 1001, a memory 1002, a communication interface 1003, and a bus 1004. The processor 1001, the memory 1002, and the communication interface 1003 are coupled via a bus (not labeled in the figure). The memory 1002 stores instructions. When the execution instructions in the memory 1002 are executed, the computing device 1000 performs the method performed by the computing device in the above method embodiment.

[0123] The computing device 1000 may be one or more integrated circuits configured to implement the above method, such as one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more field programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms. For example, when a unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call a program. For example, these units can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0124] The processor 1001 may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0125] The memory 1002 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0126] The memory 1002 stores executable program code, and the processor 1001 executes the executable program code to respectively implement the functions of the aforementioned transceiver unit and the processing unit, thereby implementing the aforementioned multi-threaded concurrent access method. That is, the memory 1002 stores instructions for executing the aforementioned multi-threaded concurrent access method.

[0127] The communication interface 1003 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1000 and other devices or a communication network.

[0128] In addition to the data bus, bus 1004 may also include a power bus, a control bus, and a status signal bus. The bus may be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a unified bus (Ubus or UB), a Compute Express Link (CXL), or a Cache Coherent Interconnect for Accelerators (CCIX). Buses can be categorized as address buses, data buses, and control buses.

[0129] Please refer to Figure 11, which is a schematic diagram of a computing device cluster provided in an embodiment of the present application. As shown in Figure 11, the computing device cluster 1100 includes at least one computing device 1000.

[0130] As shown in Figure 11, the computing device cluster 1100 includes at least one computing device 1000. The memory 1002 in one or more computing devices 1000 in the computing device cluster 1100 may store the same instructions for executing the multi-threaded concurrent access method.

[0131] In some possible implementations, the memory 1002 of one or more computing devices 1000 in the computing device cluster 1100 may also store some instructions for executing the multi-threaded concurrent access method. In other words, the combination of one or more computing devices 1000 can jointly execute the instructions for executing the multi-threaded concurrent access method.

[0132] It should be noted that the memory 1002 in different computing devices 1000 in the computing device cluster 1100 may store different instructions, each for executing part of the functions of the multi-threaded concurrent access apparatus. In other words, the instructions stored in the memory 1002 in different computing devices 1000 may implement the functions of one or more modules in the computing device cluster 1100.

[0133] In some possible implementations, one or more computing devices 1000 in the computing device cluster 1100 may be connected via a network, which may be a wide area network or a local area network.

[0134] Please refer to Figure 12, which is a schematic diagram of computer devices in a computer cluster provided by an embodiment of the present application connected via a network. As shown in Figure 12, two computing devices 1000A and 1000B are connected via a network. Specifically, the connection to the network is through a communication interface in each computing device.

[0135] In one possible implementation, the memory in the computing device 1000A stores instructions for executing the functions of the transceiver unit, while the memory in the computing device 1000B stores instructions for executing the functions of the processing unit.

[0136] It should be understood that the functions of the computing device 1000A shown in Figure 12 may also be completed by multiple computing devices. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices.

[0137] In another embodiment of the present application, a computer-readable storage medium is provided, in which computer-executable instructions are stored. When the processor of the device executes the computer-executable instructions, the device executes the method executed by the computing device in the above method embodiment.

[0138] In another embodiment of the present application, a computer program product is provided, the computer program product including computer-executable instructions stored in a computer-readable storage medium. When a processor of a device executes the computer-executable instructions, the device performs the method performed by the computing device in the above method embodiment.

[0139] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0141] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0142] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0143] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A multi-threaded concurrent access method, characterized in that: The method is applied to a computing device, the computing device is used to execute a first thread and a second thread, the first thread is used to perform a write operation on a first data unit of a shared resource, the second thread is used to perform a write operation on a second data unit of the shared resource, the first data unit and the second data unit are different data units, and the method includes: receiving a first lock request, where the first lock request is used to request a mutual trust lock for the first thread to perform a write operation on the shared resource, where the mutual trust lock is used to perform a non-exclusive write operation on the shared resource; issuing a mutual trust lock to the first thread according to the first locking request; The first thread and the second thread concurrently perform a write operation on the shared resource based on the mutual trust lock, and the second thread is a thread that has acquired the mutual trust lock.

2. The method according to claim 1, characterized in that The computing device is further configured to execute a third thread, wherein the third thread is configured to perform a write operation on the shared resource global data unit. The method further includes: receiving a second lock request, where the second lock request is used to request the third thread to perform a mutual trust lock for a concurrent write operation on the shared resource; After the first thread or the second thread acquires the mutual trust lock, the third thread waits for the mutual trust lock to be released.

3. The method according to claim 1 or 2, characterized in that: The issuing of a mutual trust lock to the first thread according to the first lock request includes: When the mutual trust lock state bit of the lock state variable is not set, setting the mutual trust lock state bit of the lock state variable according to the first lock request, and increasing the lock count bit of the lock state variable; When the mutual trust lock state bit of the lock state variable is set, the lock count bit of the lock state variable is incremented according to the first lock request.

4. The method according to claim 3, characterized in that The method further comprises: receiving a first unlocking request of the first thread, where the first unlocking request is used to request to release the mutual trust lock of the shared resource; When the lock count bit of the lock state variable is greater than 1, the lock count bit of the lock state variable is decremented according to the first unlocking request of the mutual trust lock; When the lock count bit of the lock state variable is equal to 1, the lock count bit of the lock state variable is decremented according to the mutual trust lock first unlocking request, and the mutual trust lock state bit of the lock state variable is restored to unset.

5. The method according to any one of claims 1 to 4, characterized in that The computing device is further configured to execute a fourth thread, the fourth thread being a thread that has held the mutual trust lock, and the fourth thread being configured to perform a write operation on the first data unit of the shared resource, and the method further comprising: A third lock request is received, where the third lock request is used to request a segment lock for the fourth thread to perform a write operation on a first data unit of the shared resource, where the segment lock is used to exclusively access the first data unit.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: When the first thread holds the mutual trust lock, other threads cannot hold the write lock and read lock corresponding to the shared resource, the write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource.

7. The method according to any one of claims 1 to 6, characterized in that The mutual trust lock is applied to database transaction management, and the method further includes: Multiple different threads concurrently write the transaction status in the database based on the mutual trust lock.

8. The method according to any one of claims 1 to 6, characterized in that The mutual trust lock is applied to database page management, and the method further includes: Multiple different threads concurrently perform write operations on table entries in the database page based on the mutual trust lock.

9. A multi-threaded concurrent access device, characterized in that: The device is used to execute a first thread and a second thread, the first thread is used to perform a write operation on a first data unit of a shared resource, the second thread is used to perform a write operation on a second data unit of the shared resource, the first data unit and the second data unit are different data units, and the device includes: A transceiver unit, configured to receive a first locking request, wherein the first locking request is used to request a mutual trust lock for the first thread to perform a write operation on the shared resource, and the mutual trust lock is used to perform a non-exclusive write operation on the shared resource; A processing unit, configured to issue a mutual trust lock to the first thread according to the first locking request; The first thread and the second thread of the processing unit concurrently perform a write operation on the shared resource based on the mutual trust lock, and the second thread is a thread that has acquired the mutual trust lock.

10. The device according to claim 9, characterized in that The device is further used to execute a third thread, the third thread is used to perform a write operation on the shared resource global data unit, and the transceiver unit is further used to: receiving a second lock request, where the second lock request is used to request the third thread to perform a mutual trust lock for a concurrent write operation on the shared resource; After the first thread or the second thread acquires the mutual trust lock, the third thread of the processing unit waits for the mutual trust lock to be released.

11. The device according to claim 9 or 10, characterized in that The processing unit is specifically used for: When the mutual trust lock state bit of the lock state variable is not set, setting the mutual trust lock state bit of the lock state variable according to the first lock request, and increasing the lock count bit of the lock state variable; When the mutual trust lock state bit of the lock state variable is set, the lock count bit of the lock state variable is incremented according to the first lock request.

12. The device according to claim 11, characterized in that The transceiver unit is also used for: receiving a first unlocking request of the first thread, where the first unlocking request is used to request to release the mutual trust lock of the shared resource; When the lock count bit of the lock state variable is greater than 1, the processing unit is specifically configured to decrement the lock count bit of the lock state variable according to the first unlocking request of the mutual trust lock; When the lock count bit of the lock state variable is equal to 1, the processing unit is specifically configured to decrement the lock count bit of the lock state variable according to the mutual trust lock first unlocking request, and restore the mutual trust lock state bit of the lock state variable to unset.

13. The device according to any one of claims 9 to 12, characterized in that The device is further used to execute a fourth thread, the fourth thread is a thread that has held the mutual trust lock, the fourth thread is used to perform a write operation on the first data unit of the shared resource, and the transceiver unit is further used to: A third lock request is received, where the third lock request is used to request a segment lock for the fourth thread to perform a write operation on a first data unit of the shared resource, where the segment lock is used to exclusively access the first data unit.

14. The device according to any one of claims 9 to 13, characterized in that The processing unit is also used for: When the first thread holds the mutual trust lock, other threads cannot hold the write lock and read lock corresponding to the shared resource, the write lock is used to perform exclusive write operations on the shared resource, and the read lock is used to perform non-exclusive read operations on the shared resource.

15. The device according to any one of claims 9 to 14, characterized in that The mutual trust lock is applied to database transaction management, and the processing unit is also used for multiple different threads to concurrently write transaction status in the database based on the mutual trust lock.

16. The device according to any one of claims 9 to 14, characterized in that The mutual trust lock is applied to database page management, and the processing unit is also used for multiple different threads to concurrently perform write operations on table entries in the database page based on the mutual trust lock.

17. A computing device, characterized in that The device comprises a processor coupled to a memory, wherein the processor is used to store instructions. When the instructions are executed by the processor, the computing device performs the method according to any one of claims 1 to 8.

18. A computing device cluster, characterized in that: The system comprises one or more computing devices, wherein the computing devices include a processor, the processor is coupled to a memory, and the processor is used to store instructions. When the instructions are executed by the processor, the computing device cluster performs the method according to any one of claims 1 to 8.

19. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instructions are executed, the computer is caused to perform the method according to any one of claims 1 to 8.

20. A computer program product, comprising instructions, characterized in that: When the instructions are executed, the computer implements the method according to any one of claims 1 to 8.

Images