Distributed lock processing method, system and device, storage medium and program product

Abstract

The invention discloses a distributed lock processing method, system and device, a storage medium and a program product. A shared memory and a bus protocol capable of providing the shared memory are introduced into an application process of a distributed lock; a plurality of servers used for running user threads in the distributed system are interconnected with the shared memory device through an interconnection bus corresponding to the bus protocol, lock state marks of the user threads running by the servers are recorded on the servers, and lock operation marks corresponding to the user threads are recorded on the shared memory device; and the user thread applies for the distributed lock by performing write operation on the lock operation mark in the shared memory equipment, and quickly queries whether the distributed lock is applied or not by detecting the lock state mark recorded locally. In the whole distributed lock application process, interaction is not performed based on the Ethernet any more, interaction is performed through the interconnection bus supporting the shared memory, and based on the high-speed transmission characteristic of the interconnection bus, the distributed lock application efficiency can be improved, and delay can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a distributed lock processing method, system, device, storage medium, and program product. Background Technology

[0002] With the rapid expansion of application scale, single-machine deployment can no longer meet the increasing demands of applications. Therefore, multi-machine distributed system deployment has become the mainstream architecture. In traditional single-machine deployment environments, mutex locks are used to control concurrent access to the same shared resource by different processes on a single machine. However, in distributed systems, due to the existence of multiple nodes and communication latency, mutex locks are no longer suitable. In this case, distributed locks are needed to control concurrent access to the same shared resource by different processes on multiple machines.

[0003] Distributed locks ensure that only the process that acquires the lock can access shared resources in a distributed system at any given time, thus avoiding data inconsistency issues. Distributed locks are widely used in distributed systems such as databases, Redis (RemoteDictionary server), and Zookeeper.

[0004] However, current distributed lock applications suffer from high lock operation latency and poor performance, necessitating a new distributed lock implementation scheme. Summary of the Invention

[0005] The purpose of this application is to address the problems of high lock operation latency and poor performance in current distributed lock applications, and to propose a distributed lock processing method, system, device, storage medium, and program product. This purpose is achieved through the following technical solutions.

[0006] The first aspect of this application proposes a distributed lock processing method, applied to any user thread on any server in a distributed system. The server records the lock state flag of the user thread. Multiple servers in the distributed system are interconnected with a shared memory device via an interconnect bus. The shared memory device records the lock operation flags corresponding to multiple user threads on the multiple servers that need to share a target resource. The method includes:

[0007] A first write operation is performed on the lock operation flag of any user thread recorded in the shared memory device via the interconnect bus to request the target lock of the target resource;

[0008] The shared memory device is detected to be performing a second write operation on the lock state flag of any user thread to access the target resource; wherein, the second write operation is the operation performed by the shared memory device through the interconnect bus after allocating the target lock to any user thread according to the first write operation.

[0009] A second aspect of this application proposes a distributed lock processing method applied to a shared memory device, wherein the shared memory device is interconnected with multiple servers in a distributed system via an interconnect bus, and the shared memory device records lock operation flags corresponding to multiple user threads on the multiple servers that need to share a target resource. The method includes:

[0010] Each of the multiple user threads' corresponding lock operation flags is read to check if there is a user thread requesting the target lock; the target lock corresponds to the target resource.

[0011] If a user thread has requested the target lock, select the target user thread from among the user threads that have requested the target lock;

[0012] A second write operation is performed on the lock state flag of the target user thread recorded in the server where the target user thread resides via the interconnect bus, so as to allocate the target lock to the target user thread.

[0013] A third aspect of this application proposes a distributed system comprising: multiple servers and a shared memory device interconnected via an interconnect bus, wherein multiple user threads that need to share a target resource run on the multiple servers, and each server records a lock state flag of any user thread thereon, and the shared memory device records a lock operation flag corresponding to each of the multiple user threads.

[0014] Any user thread is configured to perform a first write operation on the lock operation flag of the user thread recorded in the shared memory device through the interconnect bus, so as to request a target lock for the target resource from the shared memory device, and access the target resource if the target lock is obtained;

[0015] The shared memory device is used to read the lock operation flags corresponding to each of the multiple user threads to allocate the target lock, and to rewrite the values ​​of the lock status flags corresponding to the user threads allocated the target locks via the interconnect bus.

[0016] The fourth aspect of this application proposes a shared memory device, comprising: a shared memory module and a lock arbitration module; the shared memory module is interconnected with multiple servers via an interconnect bus, and records lock operation flags corresponding to multiple user threads on the multiple servers that need to share the target resource; the lock arbitration module includes a read unit, a selection unit, and a write unit;

[0017] The reading unit is used to perform a read operation on the lock operation flags corresponding to each of the multiple user threads to query whether there is a user thread requesting the target lock, and send the query result to the selection unit. The target lock corresponds to the target resource.

[0018] The selection unit is used to select a target user thread from the user threads that have applied for the target lock when the query result indicates that there is a user thread that has applied for the target lock, and send the selection result to the writing unit;

[0019] The write unit is configured to perform a second write operation on the lock state flag of the target user thread recorded in the server where the target user thread indicated by the selection result is located via the interconnect bus, so as to allocate the target lock to the target user thread.

[0020] The fifth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method as described in the first or second aspect above.

[0021] The sixth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method as described in the first or second aspect above.

[0022] An embodiment of the seventh aspect of this application provides a computer program product including a computer program that is executed by a processor to implement the method described in the first or second aspect above.

[0023] Based on the distributed lock processing method, system, device, storage medium, and program product described above, this application has at least the following beneficial effects or advantages:

[0024] By introducing shared memory and a bus protocol that provides shared memory into the application of distributed locks, and using an interconnect bus corresponding to the bus protocol to interconnect multiple servers running user threads in the distributed system with the shared memory device, the lock status flags of the user threads running on the servers are recorded, and the lock operation flags corresponding to each user thread are recorded in the shared memory device. User threads request a distributed lock by performing a first write operation on the lock operation flags in the shared memory device, and quickly check whether the distributed lock has been acquired by checking the second write operation of the corresponding lock status flag recorded locally. Therefore, the entire distributed lock acquisition process is no longer based on Ethernet interaction, but on an interconnect bus that supports shared memory. Based on the high-speed transmission characteristics of the interconnect bus, the acquisition efficiency of distributed locks can be improved, lock operation latency can be reduced, and thus the performance of the distributed system using distributed locks can be improved.

[0025] Since the second write operation is performed by the shared memory device after allocating the distributed lock to the user thread based on the first write operation of the user thread on the lock operation flag, the user thread needs to continuously check the second write operation on the corresponding lock state flag before the shared memory device allocates the distributed lock to the user thread. Since the lock state flag is recorded on the server, even if the user thread continuously checks the lock state flag for the second write operation, the check is performed internally on the server and will not cause lock operation delay, which can further guarantee the performance of the distributed system.

[0026] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a schematic diagram illustrating the structure of a distributed system according to an exemplary embodiment;

[0029] Figure 2 This is a flowchart illustrating a distributed lock processing method according to an exemplary embodiment;

[0030] Figure 3 A flowchart illustrating another distributed lock processing method according to an exemplary embodiment;

[0031] Figure 4 This is a schematic diagram illustrating the lock state flags and lock operation flags of each user thread according to an exemplary embodiment;

[0032] Figure 5 According to Figure 4 The diagram illustrates the lock registration process in a distributed lock processing method.

[0033] Figure 6 This diagram illustrates the user thread processing of lock acquisition and release in a distributed lock processing method.

[0034] Figure 7 This diagram illustrates the device processing of lock acquisition and lock release in a distributed lock processing method.

[0035] Figure 8 This diagram illustrates the handling of lock contention between two user threads.

[0036] Figure 9 This is a schematic diagram illustrating the structure of a shared memory device according to an exemplary embodiment;

[0037] Figure 10 This is a schematic diagram of the hardware structure of an electronic device according to an exemplary embodiment;

[0038] Figure 11 This is a schematic diagram illustrating the structure of a storage medium according to an exemplary embodiment. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0041] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0042] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0043] A distributed lock is a mechanism used in distributed systems to control concurrent access. In distributed systems, when multiple clients access the same resource simultaneously, data inconsistency can easily occur. The purpose of a distributed lock is to ensure that only the client that acquires the lock can access a resource at any given time, thus avoiding data inconsistency. The following examples, using distributed locks applied in Redis and Zookeeper distributed systems respectively, illustrate the shortcomings of traditional distributed lock applications:

[0044] (1) Redis Distributed System: Multiple user threads that need to access the same shared resource are deployed on different servers. These user threads request locks from the Redis service deployed on other servers via Ethernet. When the Redis service allocates a lock to one of the user threads, it sets an expiration time for the lock and returns information about acquiring the lock and the expiration time to that user thread, allowing the user thread to access the shared resource based on the acquired lock. When the lock's expiration time arrives, the Redis service allocates the lock to the next user thread.

[0045] (2) ZooKeeper Distributed System: ZooKeeper is an open-source distributed coordination service that includes user threads and servers. User threads and servers are interconnected via Ethernet. The server creates a parent node, and user threads that acquire the lock create an ephemeral node under the parent node of the server via Ethernet. Only one user thread is allowed to successfully create an ephemeral node at a time. Ephemeral nodes are created sequentially, with their numbers increasing sequentially. Before acquiring the lock, a user thread that successfully creates an ephemeral node will obtain all the ephemeral nodes created under the parent node and check if the number of its own ephemeral node is the smallest. If it is, it acquires the lock; otherwise, it continues to wait for the lock until the number of its own ephemeral node is the smallest, at which point it acquires the lock.

[0046] In the aforementioned distributed lock application, user threads and the server are interconnected via Ethernet. The process of a user thread acquiring a lock is cumbersome and has high latency, resulting in poor system performance. Especially in poor network environments, requests for acquiring the lock are prone to packet loss, leading to long-tail requests and further degrading system performance.

[0047] To address the aforementioned technical issues, this application introduces shared memory and a bus protocol capable of providing shared memory into the application process of distributed locks. It uses an interconnect bus corresponding to the bus protocol to interconnect multiple servers running user threads in a distributed system with shared memory devices. The lock status flags of the user threads running on the servers are recorded, and the lock operation flags corresponding to each user thread are recorded in the shared memory devices. User threads request a distributed lock by performing a first write operation on the lock operation flags in the shared memory device, and quickly check whether the distributed lock has been acquired by checking the second write operation of the corresponding lock status flags recorded locally. Therefore, the entire distributed lock acquisition process is no longer based on Ethernet interaction, but rather on an interconnect bus supporting shared memory. Based on the high-speed transmission characteristics of the interconnect bus, the acquisition efficiency of distributed locks can be improved, lock operation latency can be reduced, thereby improving the performance of distributed systems using distributed locks.

[0048] Furthermore, since the bus protocol providing shared memory can support memory-semantic read and write operations without needing to be encapsulated in network protocol message formats, communication overhead can be reduced. Moreover, based on the lossless nature of the bus protocol, the problem of long-tail requests caused by network packet loss can be solved, further improving system performance.

[0049] Furthermore, since the second write operation is performed by the shared memory device after allocating the distributed lock to the user thread based on the user thread's first write operation on the lock operation flag, the user thread needs to continuously check for the second write operation on the corresponding lock state flag before the shared memory device allocates the distributed lock to the user thread. Since the lock state flag is recorded on the server, even if the user thread continuously checks for the second write operation on the lock state flag, the check is performed internally on the server and will not cause lock operation delay, which can further guarantee the performance of the distributed system.

[0050] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0051] Example 1

[0052] Figure 1 This is a schematic diagram illustrating the structure of a distributed system according to an exemplary embodiment. Figure 1 As shown, this distributed system includes multiple servers ( Figure 1 The diagram shows servers 0 through N and shared memory devices 101 interconnected via an interconnect bus 100. Optionally, a distributed system typically deploys a large number of servers, thus these servers can... Figure 1 The switch 102 shown is interconnected with the interconnect bus and the shared memory device 101.

[0053] The interconnect bus 100 can be understood as a communication transmission line that uses a bus protocol to connect various components. This bus protocol refers to an interconnect protocol that can provide shared memory.

[0054] For example, the bus protocol could be the CXL (Compute Express Link) protocol. CXL is a high-speed interconnect technology whose main feature is allowing memory sharing and direct communication between different types of devices (such as GPUs (Graphics Processing Units), FPGAs (Field Programmable Gate Arrays), and storage devices), thereby improving overall system performance. The CXL protocol includes three sub-protocols: CXL.io, CXL.cache, and CXL.mem, all of which support read and write operations with memory semantics. Specifically, the CXL.io sub-protocol allows memory to be extended to external devices; the CXL.cache sub-protocol can improve performance by caching memory in external devices; and the CXL.memory sub-protocol allows external devices to be used as main memory, thus enabling larger memory capacities.

[0055] When using the CXL protocol, each server is connected to the USP (Upstream Port) of switch 102 via interconnect bus 100, and the server accesses shared memory device 101 via the CXL.memory sub-protocol. Simultaneously, shared memory device 101 is connected to the DSP (Downstream Port) of switch 102 via interconnect bus 100, and shared memory device 101 accesses the server's memory via the CXL.cache sub-protocol.

[0056] In a distributed system, multiple user threads that need to share a target resource run on multiple servers, such as... Figure 1 As shown, threads A and B are running on server 0, and threads C and D are running on server 1. Each server records the lock state flag for each user thread, indicating the holding state of that user thread on the target lock. A user thread can be understood as a thread created by the server for the user to run a client program; one user thread corresponds to one client program.

[0057] The shared memory device 101 records lock operation flags corresponding to multiple user threads, used to mark the operation status of user threads on the target lock. For example... Figure 1 As shown, the shared memory device 101 can record the lock operation flags of thread A, thread B, thread C, and thread D. Simultaneously, the shared memory device 101 is responsible for managing and allocating distributed locks in the distributed system.

[0058] During the distributed lock processing, any user thread can perform a first write operation on the lock operation flag of that user thread recorded in the shared memory device through the interconnect bus 100 to request a target lock for the target resource from the shared memory device 100. If the target lock is obtained, the target resource can be accessed.

[0059] The shared memory device 101 is used to read the lock operation flags corresponding to multiple user threads recorded locally in order to allocate a target lock, and to rewrite the value of the lock status flag corresponding to the user thread that has been allocated the target lock through the interconnect bus 100.

[0060] The target resource can be understood as a file or data that is accessed and called by user threads. The target lock is a distributed lock, which is a logical concept used to protect the target resource from being accessed by multiple user threads at the same time. Typically, one distributed lock is used to protect one resource.

[0061] A lock status flag can be understood as a flag recorded on the server for a user thread running on it, used to indicate the user thread's holding status of the target lock. For example, if the lock status flag is set to the first value, it indicates that the user thread holds the target lock; if the lock status flag is set to the fourth value, it indicates that the user thread does not hold the target lock. Exemplarily, the first and fourth values ​​can be 0 and 1 respectively, and this application does not limit the representation of the first and fourth values.

[0062] A lock operation flag can be understood as a flag recorded on a shared memory device for user threads to mark the operation status of the user thread on the target lock. For example, if the lock operation flag is set to the second value, it indicates that the user thread has requested the target lock; if the lock operation flag is set to the third value, it indicates that the user thread has released the target lock. Exemplarily, the second and third values ​​can be 0 and 1, respectively, and this application does not limit the representation of the second and third values.

[0063] In the above distributed lock processing scheme, the user thread and the shared memory device can realize the distributed lock acquisition process by performing write operations based on memory semantics through the interconnect bus. Instead of interacting by encapsulating the data into network protocol message format via Ethernet, communication overhead can be reduced, thereby reducing lock operation latency and ensuring that the performance of the distributed system remains stable.

[0064] To provide a more detailed explanation of the distributed lock processing procedure in the aforementioned distributed system, the following descriptions will focus on user threads on the server and shared memory devices as the execution entities.

[0065] Example 1:

[0066] Figure 2This is a flowchart illustrating an embodiment of a distributed lock processing method according to an exemplary embodiment, which is based on the above... Figure 1 In the distributed system shown, any user thread is the execution entity, such as... Figure 2 As shown, it includes the following steps:

[0067] Step 201: Perform a first write operation on the lock operation flag of any user thread recorded in the shared memory device through the interconnect bus to request the target lock of the target resource;

[0068] Step 202: The shared memory device is detected to have performed a second write operation on the lock state flag of any user thread to access the target resource; wherein, the second write operation is the operation performed by the shared memory device through the interconnect bus after the target lock is allocated to any user thread according to the first write operation.

[0069] In this embodiment, the first write operation is an operation of a user thread on a shared memory device, used to rewrite the lock operation flag of any user thread recorded on the shared memory device in order to request the target lock of the target resource.

[0070] The second write operation is the operation performed by the shared memory device through the interconnect bus after the first write operation allocates the target lock to any user thread. In other words, the second write operation is an operation of the shared memory device on the user thread on the server, used to rewrite the lock status flag of any user thread recorded on the server in order to allocate the target lock to any user thread.

[0071] The lock state flag is a flag recorded on the server for the user thread running on it, used to mark the holding state of the user thread on the target lock.

[0072] It should be noted that after any user thread performs the first write operation on the lock operation flag recorded in the shared memory device, that user thread will continuously monitor for a second write operation. The detection of the second write operation indicates that the user thread now holds the target lock. This monitoring operation occurs internally within the server and therefore does not introduce any lock operation delay.

[0073] For example, suppose that when thread A needs to access the target resource, thread A performs a first write operation on the lock operation flag of thread A recorded in the shared memory device through the interconnect bus to request the target lock of the target resource. Then, thread A detects the second write operation of the lock status flag of thread A in the shared memory device in real time. When thread A detects the second write operation, it accesses the target resource.

[0074] This completes the above. Figure 2The distributed lock processing flow shown involves the following steps: When any user thread on the server needs to access a target resource, a first write operation is performed on the lock operation flag of that user thread recorded in the shared memory device via the interconnect bus to request the target lock for the target resource. A second write operation on the lock status flag of the shared memory device is then detected. If the second write operation is detected, it indicates that the target lock has been acquired, and access to the target resource is permitted. Therefore, the entire distributed lock acquisition process is no longer based on Ethernet interaction, but rather on an interconnect bus that supports shared memory. Leveraging the high-speed transmission characteristics of the interconnect bus improves the efficiency of distributed lock acquisition, reduces lock operation latency, and thus enhances the performance of distributed systems using distributed locks.

[0075] Furthermore, since the second write operation is performed by the shared memory device after allocating the distributed lock to the user thread based on the first write operation, the user thread needs to continuously check the second write operation on the lock state flag before the shared memory device allocates the distributed lock to the user thread. Since the lock state flag is recorded on the server, even if the user thread continuously checks the lock state flag for write operations, the checks are performed internally on the server and will not cause lock operation delay, which can further guarantee the performance of the distributed system.

[0076] In one optional embodiment of this application, before step 201 above, the following specific steps are further included:

[0077] Create a lock status flag in the memory region corresponding to any user thread;

[0078] A registration request containing the location information of the lock status flag is sent to the shared memory device via the interconnect bus;

[0079] When a registration response to the registration request is received from the shared memory device via the interconnect bus, the location information of the lock operation flag carried in the registration response is recorded for any user thread; wherein, in the shared memory device, the lock operation flag is used to mark the operation mode of any user thread on the target lock.

[0080] In this embodiment, the memory region is a storage area pre-allocated by the server for any user thread, and only that user thread can access this storage area.

[0081] The lock state flag is a flag created by any user thread to mark the holding state of the target lock of the target resource by any user thread.

[0082] The location information of the lock status flag indicates the position of the lock status flag in the server to which it belongs. This location information can be pointer information or address information, etc., and this application does not limit it. Using this location information, the lock status flag in the server can be rewritten and read.

[0083] The registration request is a request for any user thread to register the target lock with the shared memory device. In addition to carrying the location information of the lock status marker, the registration request can also carry server information, thread information, etc. The server information is used to identify the server where any user thread is located, and the thread information is used to uniquely identify any user thread, so that the shared memory device can record the lock status marker location information in correspondence with the server information and thread information to complete the target lock registration.

[0084] The registration response is the response returned by the shared memory device to any user thread, and includes two response types: normal response and abnormal response. Typically, a normal response indicates successful registration and carries location information including a lock operation flag, while an abnormal response indicates registration failure and may carry error information.

[0085] The location information of the lock operation mark indicates the location of the lock operation mark in the shared memory device. This location information can also be pointer information or address information, etc. This application does not limit this. Using the location information, the lock operation mark in the shared memory device can be rewritten and read.

[0086] Correspondingly, a first write operation is performed on the lock operation flag of any user thread recorded in the shared memory device via the interconnect bus. Specifically, this includes: according to the position information of the lock operation flag, performing a first write operation on the lock operation flag of any user thread in the shared memory device via the interconnect bus to set the value of the lock operation flag to a second value, which is used to indicate the request for the target lock.

[0087] For example, suppose user thread A needs to register a target lock with a shared memory device. User thread A creates a lock status marker (Lock Status) in its corresponding memory area, then adds the location information of the lock status marker (Lock Status), server information, and thread information to the registration request, and transmits the registration request to the shared memory device through the interconnect bus. When the registration response is received from the shared memory device, the location information of the lock operation marker (Lock Acquire Ptr) carried in the registration response can be recorded in the memory area corresponding to any user thread.

[0088] In this embodiment, the user thread on the server registers the target lock with the shared memory device by using the location information of the locally created lock state flag. The shared memory device returns a response by using the location information of the lock operation flag. Thus, the user thread can rewrite the lock operation flag on the shared memory device, and the shared memory device can also rewrite the lock state flag of the user thread, which is then used to acquire and release the target lock.

[0089] In one optional embodiment of this application, after step 202 above, the following specific steps are further included:

[0090] Based on the position information of the lock operation flag, the value of the lock operation flag of any user thread in the shared memory device is set to the third value through the interconnect bus. The third value is used to indicate the release of the target lock.

[0091] Set the lock status flag of any user thread to the fourth value, which indicates that the user thread does not hold the target lock.

[0092] Based on the position information of the lock operation flag, the value of the lock operation flag of any user thread in the shared memory device is set to the third value through the interconnect bus. Specifically, the user thread performs a third write operation on the lock operation flag of the user thread in the shared memory device through the interconnect bus to rewrite the value of the lock operation flag to the third value.

[0093] The lock status flag of any user thread is set to the fourth value. Specifically, this can be done by: after setting the lock operation flag of any user thread in the shared memory device to the third value, the corresponding lock status flag is then set to the fourth value; or, after setting the lock operation flag of any user thread in the shared memory device to the third value, the shared memory device detects a fourth write operation performed on the lock status flag of any user thread via the interconnect bus, and the corresponding lock status flag is then set to the fourth value.

[0094] In this embodiment, any user thread releases the target lock by rewriting the value of the corresponding lock operation flag on the shared memory device to the third value, so that the shared memory device can allocate the target lock to other user threads. At the same time, by setting the lock state flag of any user thread to the fourth value, the lock state is set to not held, thus preventing any user thread from occupying the target lock for a long time.

[0095] Example 2:

[0096] Figure 3 This is a flowchart illustrating an embodiment of another distributed lock processing method according to an exemplary embodiment, which is based on the above... Figure 1In the distributed system shown, the shared memory device is the execution entity, such as... Figure 3 As shown, it includes the following steps:

[0097] Step 301: Perform read operations on the lock operation flags corresponding to each of the multiple user threads to check whether there is a user thread requesting the target lock; where the target lock corresponds to the target resource;

[0098] Step 302: If there are user threads that have requested the target lock, select the target user thread from among them;

[0099] Step 303: Perform a second write operation on the lock state flag of the target user thread recorded in the server where the target user thread resides via the interconnect bus, so as to allocate the target lock to the target user thread.

[0100] In this embodiment, multiple user threads are threads on multiple servers that need to share the target resource.

[0101] A lock operation flag is a flag recorded for user threads on a shared memory device to indicate the user thread's operation status on the target lock. For example, this operation status can include both a request and a release status. Therefore, by reading the lock operation flag, one can query whether a user thread is requesting the target lock.

[0102] The target user thread is selected from the user threads that applied for the target lock. Specifically, it can be selected randomly from the user threads that applied for the target lock; or, a preset scheduling algorithm can be used to randomly select a user thread from the user threads that applied for the target lock.

[0103] The second write operation is an operation on the shared memory device for user threads on the server. It is used to rewrite the value of the lock status flag of the target user thread recorded on the server, so as to allocate the target lock to the target user thread.

[0104] For example, suppose there are three user threads that need to share the target resource: thread A, thread B, and thread C. The shared memory device reads the lock operation flags corresponding to each of these three threads to check if there is a thread requesting the target lock. If all three threads are requesting the target lock, then one of the three threads is selected as the target user thread, and a second write operation is performed on the lock status flag of the target user thread recorded in the server where the target user thread is located through the interconnect bus to allocate the target lock to the target user thread.

[0105] This completes the above. Figure 3The distributed lock processing flow shown involves the shared memory device reading the lock operation flags corresponding to multiple user threads locally to check if a user thread is requesting the target lock. Then, it selects the target user thread from these requesting threads and performs a second write operation on the lock status flag of the target user thread recorded in the server where the target user thread resides via the interconnect bus, thereby allocating the target lock to the target user thread. As can be seen, the entire distributed lock operation process no longer interacts via Ethernet, but rather via an interconnect bus that supports shared memory. Leveraging the high-speed transmission characteristics of the interconnect bus improves the efficiency of distributed lock acquisition, reduces lock operation latency, and thus enhances the performance of distributed systems using distributed locks.

[0106] In an optional embodiment of this application, step 301 specifically includes: determining whether the value of the lock operation flag corresponding to each of the multiple user threads is a second value, wherein the second value is used to indicate the request for the target lock; if there is a lock operation flag with the value of the second value, it is determined that there is a user thread requesting the target lock; if there is no lock operation flag with the value of the second value, it is determined that there is no user thread requesting the target lock.

[0107] For example, assuming the second value is defined as 1, the lock operation flag of thread A is 1, the lock operation flag of thread B is 1, and the lock operation flag of thread C is 0, then the user threads that are determined to be requesting the target lock are: thread A and thread B.

[0108] In this embodiment, the second value indicates that the target lock operation status is in the request state. The shared memory device can query the user thread requesting the target lock by reading the value of the lock operation flag corresponding to each user thread.

[0109] In an optional embodiment of this application, after step 303 above, the following specific steps are further included: detecting that the server where the target user thread is located performs a third write operation on the lock operation flag of the target user thread, setting the value of the lock operation flag of the target user thread to a third value, the third value being used to indicate the release of the target lock.

[0110] For example, suppose the lock operation flag of the target user thread is set to the second value and the second value is defined as 1, indicating that the target user thread is requesting the target lock. If the lock operation flag of the target user thread is set to the third value and the third value is defined as 0, when the server where the target user thread is located detects that it is performing a third write operation on the lock operation flag, the value of the lock operation flag is set to 0 to release the target lock.

[0111] In this embodiment, the third value indicates that the target lock is in a released state. The shared memory device detects that the target user thread on the server performs a third write operation on the lock operation flag, and rewrites the value of the lock operation flag of the target user thread recorded locally to the third value, so as to facilitate the allocation of the target lock to other user threads.

[0112] In one optional embodiment of this application, step 303 specifically includes: based on the location information of the lock state flag of the target user thread, setting the value of the lock state flag of the target user thread in its server to a first value via the interconnect bus, so as to allocate the target lock to the target user thread; the first value is used to indicate that the target user thread has the right to hold the target lock.

[0113] The location information of the lock state marker is provided when the target user thread registers the target lock, and is used to indicate the storage location of the lock state marker on the server.

[0114] For example, assuming the first value is defined as 1, the value of the lock status flag in the server to which the target user thread belongs is rewritten to 1 based on the location information of the target user thread, so as to grant the target lock to the target user thread.

[0115] In this embodiment, the shared memory device rewrites the value of the corresponding lock status flag on the server to allocate the target lock to the target user thread, so that the target user thread can access the target resource when it detects that it holds the target lock permission.

[0116] In one optional embodiment of this application, the following specific steps are also included:

[0117] Receive a registration request for the target lock from any server via the interconnect bus;

[0118] If the user thread indicated by the thread information carried in the registration request does not exist among the multiple user threads that need to share the target resource in the local records, record the position information of the thread information and the lock state flag carried in the registration request, and create a lock operation flag for the user thread indicated by the thread information.

[0119] A registration response containing the location information of the lock operation flag is returned to either server via the interconnect bus.

[0120] A registration request is a request for a user thread on any server to register a target lock. The registration request mainly includes the thread information of the user thread, the server information of the server to which the user thread belongs, and the position information of the lock status marker of the user thread on the server.

[0121] The registration response is the response returned by the shared memory device to the user thread. It's important to note that if the user thread indicated by the registration request has not registered the target lock, the returned registration response contains the location information of the lock operation flag. However, if the user thread indicated by the registration request has registered the target lock—that is, if the user thread indicated by the registration request is among the multiple user threads recorded locally that need to share the target resource—then the returned registration response contains error information, which may indicate that the lock has already been registered.

[0122] Based on the above embodiments one and two, Figure 4 This is a schematic diagram illustrating the lock state flags and lock operation flags of various user threads according to an exemplary embodiment. Figure 4 As shown, for the server, each user thread located on server 0 to server N records a lock status flag and the location information pointing to the lock operation flag in the shared memory device in its corresponding memory area.

[0123] For shared memory devices, there are registration functions called by servers and lock arbiters for managing and allocating target locks. When any user thread on a server registers a target lock for a target resource, the server information is added to the host table corresponding to the registration function, and the thread table for that server is also stored in the lock arbiter. The thread table records the server information, thread information, lock status flag position information, and lock operation flag of the user thread that registered the target lock. Simultaneously, the host table also records the thread table index for each server.

[0124] Figure 5 According to Figure 4 The embodiment illustrates a schematic diagram of the lock registration process in a distributed lock processing method, as shown below. Figure 5 As shown:

[0125] First, before accessing the target resource, the user thread on the server creates a lock state flag in its corresponding memory area, and sends the lock state flag's location information, server information, and thread information in the registration request by calling the shared memory device's registration function.

[0126] Then, when the shared memory device receives a registration request, it queries the host table based on the server information in the registration request, and performs the following two different operations based on the query results:

[0127] (1) If the server information exists in the host table, it means that another user thread on the same server has registered the target lock. Then, obtain the thread table corresponding to the thread table index recorded in the host table, and use the thread information in the registration request to query the thread table. If the thread information exists in the thread table, return a registration response containing error information to the server. If the thread information does not exist in the thread table, create a lock operation flag, add a new entry to the thread table to record the location information of the lock operation flag, server information, thread information, and lock status flag, and return a registration response containing the location information of the lock operation flag to the server.

[0128] (2) If the server information is not in the host table, obtain an idle thread table, add the server information and thread table index to the host table, then create a lock operation flag, and record the server information, thread information, lock status flag position information and lock operation flag in the thread table, and return a registration response containing the lock operation flag position information to the server.

[0129] Finally, the user thread on the server records the location information of the lock operation flag carried in the registration response in its corresponding memory area.

[0130] Figure 6 This is a schematic diagram illustrating user thread processing for lock acquisition and release according to an exemplary embodiment, such as... Figure 6 As shown: When a user thread on the server needs to access a target resource, the user thread performs a first write operation on the shared memory device using the location information marked by the lock operation to request the target lock of the target resource. Then, it monitors the shared memory device for a second write operation marked by the lock status in real time. When the second write operation is detected, the user thread accesses the target resource. Finally, the user thread performs a third write operation on the shared memory device using the location information marked by the lock operation to release the target lock.

[0131] Figure 7 This is a schematic diagram illustrating a device process for lock request and lock release according to an exemplary embodiment, such as... Figure 7As shown: The shared memory device queries the lock operation flags of registered user threads to determine if a user thread has requested the target lock. If so, it selects a user thread from among those requesting the target lock as the target user thread. Then, using the position information of the target user thread's lock state flag, it performs a second write operation on the lock state flag on the server to allocate the target lock to the target user thread. At this point, the target user thread holds the lock. Next, the shared memory device checks the target user thread's lock operation flag to determine if the target lock should be released. If release is detected, the shared memory device performs a third write operation on the lock state flag on the server using the position information of the target user thread's lock state flag to update the lock state to "not held".

[0132] Figure 8 This diagram illustrates the handling of lock contention between two user threads, as shown below. Figure 8 As shown: Assume two user threads (user thread 0 and user thread 1) are running on different servers (server 0 and server 1). (a) Both user threads simultaneously request a target lock from a shared memory device via the interconnect bus. Therefore, the lock operation flag of user thread 0 on the shared memory device is changed from 0 to 1, and the lock operation flag of user thread 1 is changed from 0 to 1. (b) The lock arbitrator of the shared memory device uses an arbitration algorithm to select user thread 0 as the winner, and changes the lock state flag of user thread 0 on server 0 from 0 to 1 via the interconnect bus to update the lock state of user thread 0 to a holding state, thereby allocating the target lock to user thread 0. (c) After user thread 0 completes access to the target resource, it changes the lock operation flag of user thread 0 on the shared memory device from 1 to 0 via the interconnect bus to release the lock. (d) After the lock arbiter of the shared memory device detects that the lock operation flag of user thread 0 has been rewritten to 0, it changes the value of the lock status flag of user thread 0 on server 0 from 1 to 0 via the interconnect bus to update the lock status of user thread 0 to an unheld state. Then, it changes the value of the lock status flag of user thread 1 on server 1 from 0 to 1 via the interconnect bus to update the lock status of user thread 1 to a held state, thereby allocating the target lock to user thread 1. (e) After user thread 1 completes access to the target resource, it changes the value of the lock operation flag of user thread 1 on the shared memory device from 1 to 0 via the interconnect bus to release the lock. (f) After the lock arbiter of the shared memory device detects that the lock operation flag of user thread 1 has been rewritten to 0, it changes the value of the lock status flag of user thread 1 on server 1 from 1 to 0 via the interconnect bus to update the lock status of user thread 1 to an unheld state.

[0133] This application also provides a shared memory device corresponding to the distributed lock processing method provided in the foregoing embodiments, for executing the aforementioned distributed lock processing method.

[0134] Figure 9 This is a schematic diagram illustrating the structure of a shared memory device according to an exemplary embodiment, such as... Figure 9 As shown, the system includes a shared memory module 901 and a lock arbitration module 902. The shared memory module 901 is interconnected with multiple servers via an interconnect bus and records the lock operation flags corresponding to multiple user threads on the multiple servers that need to share the target resource. The lock arbitration module 902 has read and write permissions to the shared memory module 901. The lock arbitration module 902 can be implemented in hardware within the shared memory device, for example, based on programmable hardware such as FPGA (Field Programmable Gate Array) or CPLD (Complex Programming Logic Device), or on chips such as ASIC (Application Specific Integrated Circuit). There is no limitation on the hardware implementation structure of the lock arbitration module 902; any hardware implementation that can achieve the logic described in the above distributed lock processing method embodiments is applicable to this application embodiment.

[0135] like Figure 9 As shown, the lock arbitration module 902 includes a read unit 9021, a select unit 9022, and a write unit 9023.

[0136] The reading unit 9021 is used to perform a read operation on the lock operation flags corresponding to each of the multiple user threads to query whether there is a user thread requesting the target lock, and send the query result to the selection unit 9022. The target lock corresponds to the target resource.

[0137] The selection unit 9022 is used to select a target user thread from the user threads that have applied for the target lock when the query result indicates that there is a user thread that has applied for the target lock, and send the selection result to the writing unit 9023;

[0138] The write unit 9023 is used to perform a second write operation on the lock status flag of the target user thread recorded in the server where the target user thread indicated by the selection result is located via the interconnect bus, so as to allocate the target lock to the target user thread.

[0139] In an optional implementation, the reading unit 9021 performs a read operation on the lock operation flags corresponding to each of the plurality of user threads. Specifically, it determines whether the value of the lock operation flag corresponding to each of the plurality of user threads is a second value, wherein the second value is used to indicate that the target lock is requested. If there is a lock operation flag with the value of the second value, it is determined that there is a user thread requesting the target lock. If there is no lock operation flag with the value of the second value, it is determined that there is no user thread requesting the target lock.

[0140] In an optional implementation, after the write unit 9023 performs a second write operation on the lock status flag of the target user thread recorded in the server where the target user thread indicated by the selection result is located via the interconnect bus, it detects that the server where the target user thread is located performs a third write operation on the lock operation flag corresponding to the target user thread, and sets the value of the lock operation flag corresponding to the target user thread to a third value, which is used to indicate the release of the target lock.

[0141] In an optional implementation, the write unit 9023 performs a second write operation on the lock status flag of the target user thread recorded in the server where the target user thread resides via the interconnect bus. Specifically, based on the location information of the lock status flag of the target user thread, the write unit sets the value of the lock status flag of the target user thread in its server to a first value via the interconnect bus, so as to allocate the target lock to the target user thread. The first value is used to indicate that the target user thread has the right to hold the target lock.

[0142] Furthermore, such as Figure 9 As shown, the shared memory device also includes a registration lock module 903, which also has read and write permissions to the shared memory module 901. The registration lock module 903 can be implemented in software in the shared memory device. There is no limitation on the software implementation form of the registration lock module 903. Any software implementation that can realize the logic described in the above distributed lock processing method embodiment is applicable to the embodiment of this application.

[0143] The registration lock module 903 is configured to receive a registration request for the target lock from any server via the interconnect bus; if the user thread indicated by the thread information carried in the registration request does not exist among the multiple user threads that need to share the target resource in the local record, it records the thread information and the location information of the lock status flag carried in the registration request, and creates a lock operation flag for the user thread indicated by the thread information; and returns a registration response containing the location information of the lock operation flag to any server via the interconnect bus.

[0144] The detailed implementation methods and beneficial effects of the above-mentioned units have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0145] This application also provides an electronic device corresponding to the distributed lock processing method provided in the foregoing embodiments, for executing the aforementioned distributed lock processing method.

[0146] Figure 10 This is a hardware structure diagram of an electronic device according to an exemplary embodiment. This electronic device can be implemented as a server in a distributed system, but is not limited thereto. The electronic device interconnects shared memory devices via an interconnect bus. The shared memory devices record lock operation flags corresponding to multiple user threads on the plurality of servers that need to share a target resource. For example... Figure 9 As shown, the electronic device includes a communication interface 601, a processor 602, a memory 603, and a bus 604; wherein the communication interface 601, the processor 602, and the memory 603 communicate with each other via the bus 604. The processor 602 can execute the distributed lock processing method described above by reading and executing machine-executable instructions corresponding to the control logic of the distributed lock processing method in the memory 603. The specific content of the method is described in the above embodiments and will not be repeated here.

[0147] The memory 603 mentioned in this application can be any electronic, magnetic, optical, or other physical storage system, and can contain stored information such as executable instructions, data, etc. Specifically, the memory 603 can be RAM (Random Access Memory), flash memory, storage drive (such as hard disk drive), any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or combinations thereof. Communication between this system network element and at least one other network element is achieved through at least one communication interface 601 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc., can be used.

[0148] Bus 604 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 603 is used to store programs, and the processor 602 executes the programs after receiving execution instructions.

[0149] Processor 602 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 602 or by instructions in software form. The processor 602 can be a general-purpose processor, including a network processor (NP), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor.

[0150] The electronic device provided in this application embodiment and the distributed lock processing method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0151] This application also provides a computer-readable storage medium corresponding to the distributed lock processing method provided in the foregoing embodiments. Please refer to... Figure 11 As shown, the computer-readable storage medium is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it executes the distributed lock processing method provided in any of the foregoing embodiments.

[0152] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0153] The computer-readable storage medium provided in the above embodiments of this application and the distributed lock processing method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0154] This application also provides a computer program product corresponding to the distributed lock processing method provided in the foregoing embodiments. The computer program product includes a computer program that is executed by a processor to implement the distributed lock processing method provided in the foregoing embodiments.

[0155] The computer program products provided in the above embodiments of this application and the distributed lock processing method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0156] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0157] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0158] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for distributed lock handling, c h a r a c t e r i s e d by, The method is applied to any user thread on any server in a distributed system, a lock state mark of the any user thread is recorded in the any server, a plurality of servers in the distributed system are interconnected through an interconnection bus and a shared memory device, a plurality of lock operation marks corresponding to a plurality of user threads on the plurality of servers requiring a target resource to be shared are recorded in the shared memory device, and the method comprises the following steps: performing a first write operation on the lock operation mark of the any user thread recorded in the shared memory device through the interconnection bus to apply for a target lock of the target resource; detecting that the shared memory device performs a second write operation on the lock state mark of the any user thread to access the target resource; wherein the second write operation is an operation performed by the shared memory device through the interconnection bus after the target lock is allocated to the any user thread according to the first write operation.

2. The method of claim 1, wherein, After detecting that the shared memory device performs a second write operation on the lock state mark of the any user thread, the method further comprises the following steps: setting a value of the lock state mark of the any user thread to a first value, and the first value is used to indicate that the any user thread has the permission to hold the target lock.

3. The method according to claim 1 or 2, characterized in that, Before performing the first write operation on the lock operation mark of the any user thread recorded in the shared memory device through the interconnection bus, the method further comprises the following steps: creating a lock state mark in a memory region corresponding to the any user thread; sending a registration request containing position information of the lock state mark to the shared memory device through the interconnection bus; when a registration response to the registration request returned by the shared memory device is received through the interconnection bus, recording position information of a lock operation mark carried by the registration response for the any user thread; in the shared memory device, the lock operation mark is used to mark an operation mode of the any user thread on the target lock.

4. The method of claim 3, wherein, The first write operation on the lock operation mark of the any user thread recorded in the shared memory device through the interconnection bus comprises the following steps: according to the position information of the lock operation mark, performing the first write operation on the lock operation mark of the any user thread in the shared memory device through the interconnection bus to set a value of the lock operation mark to a second value; wherein the second value is used to indicate that the target lock is applied.

5. The method of claim 3, wherein, After accessing the target resource, the method further comprises the following steps: according to the position information of the lock operation mark, setting a value of the lock operation mark of the any user thread in the shared memory device to a third value through the interconnection bus; the third value is used to indicate that the target lock is released; setting a value of the lock state mark of the any user thread to a fourth value; the fourth value is used to indicate that the any user thread does not have the permission to hold the target lock.

6. A method of distributed lock handling, c h a r a c t e r i s e d by, The method is applied to a shared memory device, the shared memory device is interconnected with a plurality of servers in a distributed system through an interconnection bus, and the shared memory device records lock operation marks corresponding to a plurality of user threads requiring a target resource to be shared on the plurality of servers. The method comprises the following steps: reading the lock operation marks corresponding to the plurality of user threads to query whether there is a user thread applying for a target lock; the target lock corresponds to the target resource; if there is a user thread applying for the target lock, selecting a target user thread from the user threads applying for the target lock; performing a second write operation on the lock state mark of the target user thread recorded in the server where the target user thread is located through the interconnection bus to allocate the target lock to the target user thread.

7. The method of claim 6, wherein, reading the lock operation marks corresponding to the plurality of user threads to query whether there is a user thread applying for a target lock comprises: determining whether the values of the lock operation marks corresponding to the plurality of user threads are a second value; the second value is used to indicate that the target lock is applied for; if there is a lock operation mark with the second value, it is determined that there is a user thread applying for the target lock; if there is no lock operation mark with the second value, it is determined that there is no user thread applying for the target lock.

8. The method of claim 6, wherein, After performing the second write operation on the lock state mark of the target user thread recorded in the server where the target user thread is located through the interconnection bus, the method further comprises: detecting that the server where the target user thread is located performs a third write operation on the lock operation mark corresponding to the target user thread, and setting the value of the lock operation mark corresponding to the target user thread to a third value; the third value is used to indicate that the target lock is released.

9. The method of claim 6, wherein, performing the second write operation on the lock state mark of the target user thread recorded in the server where the target user thread is located through the interconnection bus comprises: according to the position information of the lock state mark of the target user thread, setting the value of the lock state mark of the target user thread in the server to a first value through the interconnection bus to allocate the target lock to the target user thread; the first value is used to indicate that the target user thread has the permission to hold the target lock.

10. The method according to any one of claims 6-9, characterized in that, The method further comprises: receiving a registration request for the target lock sent by any server through the interconnection bus; if there is no user thread indicated by thread information carried in the registration request in the plurality of user threads requiring the target resource to be shared recorded locally, recording the thread information and position information of a lock state mark carried in the registration request, and creating a lock operation mark for the user thread indicated by the thread information; returning a registration response containing the position information of the lock operation mark to the any server through the interconnection bus.

11. A distributed system, characterized by The method comprises: A plurality of servers and a shared memory device interconnected through an interconnection bus, wherein a plurality of user threads requiring a target resource to be shared are running on the plurality of servers, and a lock state marker of any user thread is recorded in any server, and a lock operation marker corresponding to each of the plurality of user threads is recorded in the shared memory device; Any user thread is configured to perform a first write operation on the lock operation marker of any user thread recorded in the shared memory device through the interconnection bus to apply for a target lock of the target resource from the shared memory device, and in the case of applying for the target lock, access the target resource; The shared memory device is configured to perform a read operation on the lock operation marker corresponding to each of the plurality of user threads to allocate the target lock, and rewrite the value of the lock state marker corresponding to the user thread to which the target lock is allocated through the interconnection bus.

12. A shared memory device, comprising: Comprise: A shared memory module and a lock arbitration module; the shared memory module is interconnected with a plurality of servers through an interconnection bus, and records a lock operation marker corresponding to each of a plurality of user threads requiring a target resource to be shared on the plurality of servers; the lock arbitration module comprises a read unit, a selection unit and a write unit; The read unit is configured to perform a read operation on the lock operation marker corresponding to each of the plurality of user threads to query whether there is a user thread applying for a target lock, and send the query result to the selection unit, wherein the target lock corresponds to the target resource; The selection unit is configured to select a target user thread from the user thread applying for the target lock in the case that the query result indicates that there is a user thread applying for the target lock, and send the selection result to the write unit; The write unit is configured to perform a second write operation on the lock state marker of the target user thread recorded in the server where the target user thread is located through the interconnection bus to allocate the target lock to the target user thread.

13. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the method of any one of claims 1-10.

14. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-10.

15. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-10.

Images