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

Abstract

Provided in the embodiments of the present disclosure are a distributed lock processing method, and a device, a system, a storage medium and a program product. In the embodiments of the present disclosure, a bus protocol capable of providing a shared memory and the shared memory provided by the bus protocol are introduced into distributed lock application and release processes; a plurality of servers that host client processes in a distributed system are interconnected to a shared memory module by means of an interconnection bus corresponding to the bus protocol capable of providing the shared memory; lock flag regions corresponding to the client processes are maintained in the shared memory module; the client processes and a lock resource management object implement the application and release of distributed locks by means of reading and writing operations performed on the lock flag regions in the shared memory module; interaction in the entire distributed lock application process is no longer performed by means of an Ethernet, but is performed by means of the interconnection bus that supports the shared memory; and by virtue of the advantages of bus transmission, the efficiency of distributed lock application can be improved, the latency can be reduced, and the performance of the distributed system that relies on distributed locks can be improved.

Description

[0001] TECHNICAL FIELD The present disclosure relates to the field of cloud computing technology, and more particularly to a distributed lock processing method, device, system, storage medium, and program product. BACKGROUND With the rapid expansion of application scale, single-machine deployment can no longer meet the increasingly diverse application needs. Multi-machine distributed cluster deployment has become the mainstream architecture. Similar to traditional single-machine deployment, distributed architectures also face the issue of concurrency control when different processes on multiple machines access the same shared resource. Distributed locks are a mainstream solution for concurrency control when different processes on multiple machines access the same shared resource. They are widely used in distributed systems such as databases, Redis (Remote Dictionary Server), and Zookeeper. Distributed locks ensure that only the process that has obtained the lock can access the shared resource at a time, preventing data corruption caused by multiple processes accessing the shared resource simultaneously. However, current distributed lock applications suffer from problems such as high latency and poor performance. Therefore, a new distributed lock implementation solution is urgently needed. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a distributed lock processing method, device, system, storage medium, and program product for improving distributed lock application efficiency, reducing latency, and enhancing the performance of distributed systems that rely on distributed locks. Embodiments of the present disclosure provide a distributed lock processing method, applied to any client process on any server in a distributed system. Multiple servers in the distributed system are interconnected via a target interconnect bus to a shared memory module. The shared memory module maintains lock tag areas corresponding to multiple client processes on the multiple servers that need to share a target resource object. The method comprises: performing a write operation on the lock tag area corresponding to the client process in the shared memory module via the target interconnect bus to apply for a target lock from a lock resource management object; wherein the lock resource management object is responsible for allocating the target lock and overwriting the lock tag area corresponding to the client process allocated to the target lock; performing a read operation on the lock tag area corresponding to the client process in the shared memory module via the target interconnect bus to query whether the target lock has been applied for; and, if the target lock has been applied for, accessing the target resource object corresponding to the target lock.An embodiment of the present disclosure also provides a distributed lock processing method, which is applied to a lock resource management object in a distributed system, wherein multiple servers in the distributed system are interconnected through a target interconnection bus to share a memory module, and the shared memory module maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share a target resource object. The method comprises: performing a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to query whether there is a client process that has applied for a target lock corresponding to the target resource object; if there is a client process that has applied for the target lock, determining a target client process from the client processes that have applied for the target lock; and rewriting the lock mark area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. An embodiment of the present disclosure further provides a distributed system, comprising: multiple servers, a lock resource management object, and a shared memory module interconnected with the multiple servers via a target interconnection bus; multiple client processes that need to share a target resource object are running on the multiple servers, and the shared memory module maintains lock mark areas corresponding to the multiple client processes; any client process is configured to perform read and write operations on the lock mark area corresponding to it in the shared memory module via the target interconnection bus to apply for a target lock from the lock resource management object, and access the target resource object if the target lock is applied for; the lock resource management object is configured to perform a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to allocate the target lock, and rewrite the lock mark area corresponding to the client process allocated to the target lock.An embodiment of the present disclosure further provides an electronic device, comprising: a shared memory module and a lock resource management component; the shared memory module is interconnected with multiple servers via a target interconnect bus, and maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share a target resource object; wherein the lock resource management component comprises: a read component, a determination component, and a write component implemented based on hardware; the read component is responsible for performing a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to query whether there is a client process that has applied for a target lock corresponding to the target resource object, and providing the query result to the determination component; if the query result provided by the read component indicates that there is a client process that has applied for the target lock, the determination component determines a target client process from the client processes that have applied for the target lock and notifies the write component; the write component rewrites the lock mark area corresponding to the target client process in the shared memory module in accordance with the notification of the determination component to allocate the target lock to the target client process. Embodiments of the present disclosure also provide an electronic device, comprising: a memory and a processor; the memory configured to store a computer program; and the processor, coupled to the memory and configured to execute the computer program to implement the steps of the method provided in the embodiments of the present disclosure. Embodiments of the present disclosure also provide a computer-readable storage medium storing the computer program. When the computer program is executed by the processor, the processor is enabled to implement the steps of the method provided in the embodiments of the present disclosure. Embodiments of the present disclosure also provide a program product containing the computer program / instructions. When the computer program / instructions are executed by the processor, the processor is enabled to implement the steps of the method provided in the embodiments of the present disclosure. In this embodiment, a bus protocol capable of providing shared memory and the shared memory it provides are incorporated into the distributed lock application and release process. Multiple servers hosting client processes in a distributed system are interconnected with a shared memory module via an interconnect bus corresponding to the bus protocol capable of providing shared memory. A lock tag area corresponding to each client process is maintained in the shared memory module. The client process and the lock resource management object implement distributed lock application and release by performing read and write operations on the lock tag area in the shared memory module. The entire distributed lock application process no longer interacts over Ethernet, but rather over an interconnect bus supporting shared memory. Leveraging the advantages of bus transmission, this improves distributed lock application efficiency, reduces latency, and enhances the performance of distributed systems that rely on distributed locks.BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation on the present disclosure. In the accompanying drawings: FIG1 is a schematic diagram of the structure of a distributed system provided by an exemplary embodiment of the present disclosure; FIG2a is a schematic diagram of a deployment implementation method of a lock resource management object provided by an exemplary embodiment of the present disclosure; FIG2b is a schematic diagram of a deployment implementation method of a lock resource management object provided by another exemplary embodiment of the present disclosure; FIG2c is a schematic diagram of a deployment implementation method of a lock resource management object provided by yet another exemplary embodiment of the present disclosure; FIG3 is a schematic diagram of multiple lock flags corresponding to multiple client processes provided by an exemplary embodiment of the present disclosure; FIG4a is a schematic diagram of a flow from any client process applying for a lock resource to releasing the lock resource provided by an embodiment of the present disclosure; FIG4b is a schematic diagram of a flow from a central service process receiving a lock resource application to releasing the lock resource provided by an embodiment of the present disclosure; FIG5a is a schematic diagram of a state machine for three lock flags of a client process provided by an embodiment of the present disclosure; FIG5b is a schematic diagram of valid state transition conditions of a state machine for a lock flag provided by an embodiment of the present disclosure; FIG6a, FIG6b, FIG6c, FIG6d, FIG6e, and FIG6f are schematic diagrams of a flow diagram of two client processes competing for a lock; FIG7a is a schematic diagram of a flow diagram of a distributed lock processing method provided by an embodiment of the present disclosure; Figure 7b is a flow chart of another distributed lock processing method provided by an embodiment of the present disclosure; Figure 8a is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure; and Figure 8b is a schematic diagram of the structure of another electronic device provided by an embodiment of the present disclosure. Detailed Description of Implementation Methods To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art without inventive effort based on the embodiments of the present disclosure are within the scope of protection of the present disclosure. 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, and displayed data, etc.) involved in the present disclosure are all authorized by the user or fully authorized by all parties. 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 reject. Furthermore, the various models involved in the present disclosure (including but not limited to language models or large models) comply with relevant laws and standards.Distributed locks are a mainstream solution for concurrency control when different processes on multiple machines access the same shared resource. They are widely used in distributed systems such as databases, Redis, and Zookeeper. This article uses the distributed lock solutions used in the Redis distributed system (referred to as Redis distributed locks) and the Zookeeper distributed system (referred to as Zookeeper distributed locks) to illustrate the problems of traditional distributed locks in applications.

[0002] Redis distributed lock: Multiple concurrent threads that need to access the same shared resource are deployed on different servers. These concurrent threads apply for a lock from a Redis service deployed on another server via Ethernet. The Redis service assigns the lock to one of the threads, such as thread A, and sets a lock expiration time for thread A. The Redis service returns the lock acquisition information and the lock expiration time to thread A, allowing thread A to access the shared resource based on the acquired lock. When the lock expiration time reaches, the lock is assigned to the next thread, and so on.

[0003] Zookeeper distributed lock: Zookeeper is a distributed coordination service, including client threads, client listeners and servers. The client threads and servers are interconnected through Ethernet. The server creates a parent node. The client thread that obtains the lock creates a temporary node under the parent node of the server through the network. One client thread is allowed to successfully create a temporary node at the same time. Temporary nodes are created in sequence and their numbers increase in sequence. Before preempting the lock, the client thread that successfully creates a temporary node needs to obtain all temporary nodes created under the parent node and determine whether the number of the temporary node it created is the smallest. If so, it acquires the lock. If not, it is in a waiting state, waiting for the notification sent by the previous temporary node when it is deleted. When it receives the notification, it determines that it is its turn to obtain the lock. In the aforementioned distributed lock application, concurrent threads or processes are connected to the server via Ethernet. The process of obtaining locks is cumbersome and time-consuming, leading to poor system performance. In particular, when network congestion and packet loss occur, requests for obtaining locks are lost, which can easily lead to long-tail requests. Consequently, threads or processes cannot access shared resources due to long periods of lock acquisition, resulting in significant system performance jitter. To address the above technical issues, in embodiments of the present disclosure, a bus protocol capable of providing shared memory and the shared memory it provides are introduced into the distributed lock application and release process. Multiple servers hosting client processes in a distributed system are interconnected with a shared memory module via an interconnect bus corresponding to the bus protocol capable of providing shared memory. A lock tag area corresponding to each client process is maintained in the shared memory module. The client process and the lock resource management object implement distributed lock application and release by performing read and write operations on the lock tag area in the shared memory module. The entire distributed lock application process no longer interacts via Ethernet, but rather via an interconnect bus supporting shared memory. Leveraging the advantages of bus transmission, this improves distributed lock application efficiency, reduces latency, and enhances the performance of distributed systems that rely on distributed locks. Furthermore, bus protocols capable of providing shared memory can provide read and write operations with memory semantics, eliminating the need for encapsulation into network message formats and reducing communication protocol overhead. Furthermore, bus protocols capable of providing shared memory can prevent packet loss during end-to-end communication, avoiding the long-tail request problem caused by network packet loss, further reducing system performance jitter and improving system performance stability. The following describes in detail the technical solutions provided by various embodiments of the present disclosure, with reference to the accompanying drawings. Figure 1 is a schematic diagram of the structure of a distributed system provided by an embodiment of the present disclosure.As shown in FIG1 , the distributed system 100 may include multiple servers (server 101 and server 102 shown in FIG1 ), a lock resource management object 103, and a shared memory module 105 interconnected with the multiple servers via a target interconnect bus 104. The target interconnect bus 104 refers to an information transmission line that connects various components using a target interconnect protocol. In this embodiment, the target interconnect protocol refers to a protocol that can provide shared memory. For example, in some embodiments, the target interconnect protocol may be the Compute Express Link (CXL) protocol. The CXL protocol is an interconnect protocol based on an extension of the high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIE) protocol. The CXL protocol includes three sub-protocols: CXL.io, CXL.cache, and CXL.mem.o, and supports read and write operations with memory semantics. The CXL.io protocol is used for initialization, linking, device discovery and enumeration, and register access; the CXL.cache protocol allows devices to locally store cache lines; and the CXL.memo protocol allows devices to become fully coherent memory devices, which can be used as system random access memory (RAM) and / or persistent memory. Any server can be a conventional server device, a cloud server, or a virtual machine, without limitation in this embodiment. When there are a large number of servers, multiple servers can be interconnected with a shared memory module 105 via a switch 106 and a target interconnect bus 104 as shown in FIG1 . The switch 106 and the target interconnect bus 104 follow the same target interconnect protocol. Multiple client processes that need to share target resource objects run on the multiple servers. The target resource objects can be shared resources such as database records, files, and caches in a distributed system. As shown in FIG1 , a client process 101a runs on server 101, and a client process 102a runs on server 102. The shared memory module 105 maintains lock mark areas corresponding to the multiple client processes.As shown in Figure 1 , the shared memory module 105 can maintain a lock mark area 105a corresponding to the client process 101a and a lock mark area 105b corresponding to the client process 102a. The lock resource management object 103 is an object used to manage distributed lock resources in the distributed system. This lock resource management object 103 can be implemented as hardware or as a software module. The embodiment shown in Figure 1 does not limit the deployment and implementation of the lock resource management object 103. In some exemplary embodiments, the lock resource management object 103 can be implemented as software, specifically as a central service process. As shown in Figure 2a , the distributed system 100 further includes a control device 107. The control device 107 can be interconnected with the shared memory module 105 via a target interconnect bus 104. Alternatively, the lock resource management object 103 can be a central service process running on the control device 107. The control device 107 can be implemented as a server as shown in Figure 2a or as a terminal-side device, but this embodiment does not impose any limitations. In other exemplary embodiments, the lock resource management object 103 is a central service process running on the electronic device 108 to which the shared memory module 105 belongs, as shown in FIG2b . That is, the lock resource management object 103 and the shared memory module 105 run simultaneously on the electronic device 108. In still other exemplary embodiments, the lock resource management object 103 is located on the electronic device 108 to which the shared memory module 105 belongs and is a hardware-implemented lock resource management component, as shown in FIG2c . The hardware may be implemented using, but is not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD). 2a, 2b and 2c are different in that the lock resource management object 103 accesses the shared memory module 105 in different ways. In FIG2a, the lock resource management object 103 can be interconnected with the shared memory module 105 via the target interconnect bus 104.In Figures 2b and 2c, the lock resource management object 103 and the shared memory module 105 are located on the same device and can directly access the shared memory module 105. Other operational processes are identical or similar, so the following embodiments will be described using the system architecture shown in Figure 2a. The lock flag area corresponding to any client process is configured to record information about the lock resource usage corresponding to that client process. The lock flag areas of multiple client processes are independent of each other. Each lock flag area corresponding to a client process may have one or more lock status flag bits. Each lock status flag area may support write, read, and delete operations. Write and delete operations can enable repeated overwriting of the lock flag bits. Client processes and the lock resource management object 103 can implement distributed lock application and management by overwriting the lock status flag area. This is described below in an exemplary manner. Any client process is configured to perform read and write operations on the corresponding lock tag area in the shared memory module 105 via the target interconnect bus 104 to request a target lock from the lock resource management object 103. The target lock corresponds to a target resource object. The target lock is configured to lock the target resource to reduce the risk of data contention and data inconsistency. After obtaining the target lock, the client can access the target resource object. For example, client process 101a can perform read and write operations on the corresponding lock tag area 105a to request a target lock from the lock resource management object 103. Client process 102a can perform read and write operations on the corresponding lock tag area 105b to request a target lock from the lock resource management object 103. The lock resource management object 103 is configured to perform read operations on the lock tag areas corresponding to multiple client processes in the shared memory module 105 to query whether there is a client process requesting the target lock. If a client process has requested the target lock, the lock resource management object 103 can identify the target client process from the client processes requesting the target lock and rewrite the lock tag area corresponding to the target client process in the shared memory module 105 to allocate the target lock to the target client process. For example, the lock resource management object 103 can read the lock tag area 105a to allocate the target lock to the client process 101a. After allocating the target lock, the lock resource management object 103 can rewrite the lock tag area 105a to indicate that the target lock has been allocated. In some scenarios, multiple client processes may simultaneously request lock resources.In this case, when determining the target client process from the client processes applying for the target lock, the lock resource management object 103 may optionally randomly select a client process as the target client process. Alternatively, the lock resource management object 103 may select the target client process from the client processes applying for the target lock based on at least one of the waiting time, the number of lock requests, and the priority of the client process applying for the target lock. For example, the lock resource management object 103 may sort the client processes applying for the target lock in descending order based on the waiting time, and select the target client processes in order starting with the client process with the longest waiting time. For another example, the lock resource management object 103 may sort the client processes applying for the target lock in descending order based on the number of lock requests, and select the target client processes in order starting with the client process with the fewest lock requests. The priority can be predefined or determined based on the type of client process, which is not limited in this embodiment. Optionally, the lock resource management object 103 can also use the RR scheduling algorithm (Round-Robin Scheduling Algorithm) to select a target client process from client processes applying for the target lock. The core concept of the RR scheduling algorithm is to maintain a ready queue and set a timer. The timer starts counting each time a target lock is allocated to a client process. Each client process is assigned a fixed time slice, during which it can exclusively hold the target lock. If a client process fails to release the target lock within the time slice, it is suspended and placed at the end of the ready queue, awaiting its next turn to acquire the lock resource. Based on this implementation, the lock resource management object 103 can provide differentiated lock resource allocation services to different client processes based on their actual conditions, thereby balancing the lock resource demands of different client processes. Different values ​​written into the lock flag area can represent different lock resource usage conditions. In the lock flag area, the value written to any lock flag bit can be a numeric value or a string. The numeric value can be a binary bit value or a decimal value, which is not limited in this embodiment. Taking a bit value as an example, the bit value written to any lock flag bit can be one or more.One or more bit values ​​can be defined with different semantics to distinguish different usage information of lock resources. The following will provide exemplary explanations based on different lock resource usage scenarios. In some exemplary embodiments A, a client process needs to apply for a target lock from the lock resource management object 103. When applying for a target lock from the lock resource management object 103, any client process can write a first value to the lock tag area corresponding to the client process in the shared memory module 105 via the target interconnect bus 104 to apply for the target lock from the lock resource management object. The first value can be any numerical value or string, and the semantics of the first value are predefined as "applying for the target lock." In this embodiment, the lock resource management object 103 can read the lock tag areas corresponding to multiple client processes in the shared memory module 105 to determine whether a lock tag area containing the first value exists. Alternatively, the lock resource management object 103 can periodically read the lock tag areas corresponding to multiple client processes in a polling manner. If a lock tag area containing the first value exists, the lock resource management object 103 can determine that a client process has applied for the target lock. For example, if the lock tag area corresponding to a client process contains the first value, the client process is determined to be the client process that has applied for the target lock. Conversely, if a lock tag area containing the first value does not exist, the lock resource management object 103 can determine that a client process has not applied for the target lock. The client process that has applied for the target lock is referred to as the target client process. The lock resource management object 103 can write a third value into the lock tag area corresponding to the target client process in the shared memory module 105 to assign the target lock to the target client process. The third value can be any numeric value or string, and its semantics are predefined as "target lock applied for." Accordingly, when any client process (e.g., the target client process) queries whether it has applied for the target lock, it can read the lock tag area corresponding to the client process in the shared memory module 105 via the target interconnect bus 104 to determine whether the third value exists in the lock tag area. If the third value exists, the client process can determine that the target lock has been applied for. If the third value does not exist, the client process can determine that the target lock has not been applied for. Optionally, the lock flag area of ​​any client process may include one or more lock flag bits, and any lock flag bit supports write operations, read operations, and delete operations. Based on write and delete operations, the lock flag bit can be repeatedly rewritten.If the lock mark area includes multiple lock mark bits, the multiple lock mark bits can be configured to record different types of information. For example, among the multiple lock mark bits, at least one lock mark bit may be configured to record information about the client process's operations on the distributed lock, and at least one lock mark bit may be configured to record status information about the distributed lock. This will be described below with examples. In some optional embodiments, the lock mark area corresponding to any client process includes an application mark bit and a status mark bit. As shown in Figure 3, the lock mark area of ​​each client process on servers 1 through N may include an application mark bit and a status mark bit. The application mark bits and status mark bits of the multiple client processes are independent of each other. For any client process, when it needs to apply for a target lock from the lock resource management object 103, the client process can specifically set the corresponding application mark bit in the shared memory module 105 to a first value via the target interconnect bus 104 to apply for the target lock. The application mark bit may have a default value, which may be set to a second value. The second value can be any numerical value or string. The semantics of the second value are predefined as indicating that the lock resource has not been requested. For example, the first value can be 1 and the second value can be 0; or, the first value can be 0 and the second value can be 1. For another example, the first value can be 100 and the second value can be 001. This embodiment does not impose any restrictions on this. Any client process can perform a lock resource request operation by overwriting the default value of the request flag bit. Accordingly, the lock resource management object 103 is specifically configured to read the request flag bits corresponding to multiple client processes in the shared memory module 105 to determine whether there is an request flag bit with the first value. If there is, the target client process is determined from the client processes that have requested the target lock based on the client process corresponding to the request flag bit with the first value. The lock resource management object 103 may set the status flag bit corresponding to the target client process to the third value to allocate the target lock to the client process. The status flag bit may have a default value, which may be set to the fourth value. The fourth value can be any numeric value or string. The semantics of this fourth value are predefined as indicating that the client process is not occupying the lock resource. The lock resource management object 103 can modify the lock resource allocation status by overwriting the default value of the status flag. The third value can be 1 and the fourth value can be 0; alternatively, the third value can be 0 and the fourth value can be 1. For example, in the default state, the status flag is 0.After allocating the target lock to the client process, the lock resource management object 103 may change the status flag from 0 to 1 to indicate that the target lock has been allocated to the corresponding client process. Alternatively, any client process may read its corresponding status flag and determine that it has successfully applied for the target lock if the status flag is a third value. For example, a client process may change its corresponding request flag from 0 to 1 to apply for the target lock from the lock resource management object 103. If the lock resource management object 103 finds that the request flag is 1, it may allocate the target lock to the client process. After allocating the target lock, the lock resource management object 103 may change the corresponding status flag for the client process from 0 to 1 to indicate that the target lock has been allocated to the client process. If the client process finds that the status flag is 1, it may determine that it has successfully acquired the target lock. In some optional embodiments, before any client process sets the request flag corresponding to the client process in the shared memory module 105 to the first value via the target interconnect bus 104, it may read the status flag corresponding to the client process in the shared memory module 105 via the target interconnect bus 104 to determine whether the status flag is a third value. If the status flag is the third value, the client process may continue to read the status flag via the target interconnect bus 104 until the status flag is set to a fourth value. Alternatively, if the status flag is the fourth value, the client process may execute an operation to set the request flag corresponding to the client process in the shared memory module 105 to the first value via the target interconnect bus 104. Based on this embodiment, before applying for a lock resource, any client process may determine whether it currently occupies the lock resource by reading the value of its corresponding status flag. If the status flag is the third value, this indicates that the client process currently occupies the lock resource and needs to wait until the currently occupied lock resource is released before applying for the lock resource. When the status flag is the fourth value, it indicates that the client process is not currently occupying the lock resource. In this case, the client process can request the lock resource from lock resource management object 103 by modifying its corresponding request flag. In some exemplary embodiments B, the client process needs to request the release of the target lock from lock resource management object 103. Optionally, the lock flag area corresponding to any client process also includes a release flag. The release flag corresponding to any client process is configured to record the client process's request to release the lock resource.Accordingly, if any client process is implemented as a target client process that has been allocated a target lock as described in the aforementioned embodiment, the client process can set the corresponding release flag bit in the shared memory module 105 to the fifth value via the target interconnect bus 104 to release the target lock. The fifth value can be any numerical value or string, and its semantics are predefined as: the client process requests to release the lock resource. The release flag bit can have a default value, which can be set to a sixth value. The sixth value can be any numerical value or string, and its semantics are predefined as: the client process's lock resource has been reclaimed. The client process can release the lock resource by overwriting the default value of the release flag bit. The fifth value can be 1 and the sixth value can be 0; or the fifth value can be 0 and the sixth value can be 1. After the client process completes its use of the target lock, it can change the release flag bit from 0 to 1 to request the lock resource management object 103 to reclaim the target lock. Accordingly, the lock resource management object 103 is further configured to read the release flag corresponding to the target client process in the shared memory module 105 and, if the release flag is at the fifth value, set the status flag corresponding to the target client process to the fourth value to reclaim the target lock. For example, when the lock resource management object 103 finds a value of 1 in the release flag of a client process, the target lock allocated to the client process may be reclaimed and the status flag corresponding to the client process may be set to 0 to indicate that the target lock has been reclaimed. Optionally, when any client process releases the target lock, the request flag corresponding to the client process is set to the second value. The operation of setting the request flag to the second value can be performed by the client process or by the lock resource management object 103. Each of these operations will be described below with examples. In some optional embodiments, when any client process releases the target lock, it sets the request flag corresponding to the client process in the shared memory module 105 to the second value via the target interconnect bus 104 to release the target lock. That is, the client process may change its corresponding request flag from 1 to 0 to release the target lock. In other optional embodiments, when reclaiming the target lock, the lock resource management object 103 may set the request flag corresponding to the target client process to the second value, allowing the target client process to apply for the target lock again. Specifically, when allocating the target lock to the target client process, the lock resource management object 103 may simultaneously set the status flag to the fourth value and the request flag to the second value.Furthermore, when any client process uses the lock resource again, it can request the target lock from the lock resource management object 103 by querying the status flag value and rewriting the request flag value. For details, please refer to the description of the aforementioned embodiment A and will not be further described. The request flag, status flag, and release flag described in the aforementioned embodiment may be logically distinct lock flag areas. In some embodiments, these multiple flags may reside in the same physical location in the shared memory module 105. In this manner, the request flag, status flag, and release flag may be distinguished by setting values ​​corresponding to different semantics. It is worth noting that, in some optional embodiments, the lock flag area of ​​any client process may include a lock flag bit that supports write, read, and delete operations. The lock flag bit can be repeatedly rewritten based on write and delete operations. The first, third, and fifth values ​​may be written to the lock flag area by rewriting. For example, when a client process needs to use a lock resource, it may write a first value (e.g., first value = 1, or first value = 001) in the lock flag bit to request a target lock from the lock resource management object 103. When the lock resource management object 103 finds the first value in the lock flag bit, it may allocate the target lock to the client process. After allocating the target lock, the lock resource management object 103 may delete the first value in the lock flag bit and write a third value (e.g., third value = 2, or third value = 101) in the lock flag bit to indicate that the target lock has been allocated to the client process. When the client process finds the third value in the lock flag bit, it can determine that it has successfully acquired the target lock. After using the target lock, the client process may delete the third value in the lock flag bit and write a fifth value (e.g., fifth value = 3, or third value = 011) in the lock flag bit to indicate that the target lock has been released. When the lock resource management object 103 finds the fifth value in the lock flag, it can reclaim the target lock allocated to the client process. In this implementation, lock resource application, allocation, and release operations can be implemented based on a lock flag in shared memory, which reduces the complexity of lock resource management and helps reduce the memory space required for lock resource management. In some exemplary embodiments, when any client process needs to access the target resource object, it can request a lock resource from the lock resource management object 103 based on shared memory.Optionally, a client process may send a request to the lock resource management object 103 to share a target lock, causing the lock resource management object 103 to create a lock mark area corresponding to the client process in the shared memory module 105 and return the location information of the lock mark area. The client process may receive the location information of the lock mark area returned by the lock resource management object 103 and perform read and write operations on the lock mark area based on the location information. The following further illustrates the distributed lock processing system provided by the embodiments of the present disclosure with reference to the figures. Figure 4a illustrates the execution flow from a client process requesting a lock resource to releasing the lock resource. As shown in Figure 4a, when a client process receives a query request for a target resource object, it may query its own lock status and determine whether it currently occupies the lock resource. To query the lock status, the client process may read the value of the status flag. If the value of the status flag is 0, it is determined that the client process does not currently occupy the lock resource. If the value of the status flag is 1, it is determined that the client process currently occupies the lock resource. If the lock resource is already occupied, the client process can wait for it to be released. If the lock resource is not occupied, a lock grab request can be initiated. When initiating a lock grab request, the client process can set its corresponding application flag to 1 and the release flag to 0o. After that, the client process can query the lock status. To query the lock status, the client process can read the value of the status flag. If the value of the status flag is 1, the client process is determined to have acquired the lock resource. If the value of the status flag is 0, the client process is determined to have not yet acquired the lock resource. If the client process has currently acquired the lock resource, it can access the target resource object based on the acquired lock resource. After the access is completed, the client process can initiate a lock release request. When initiating a lock release request, the client process can set the release flag to 1 and the request flag to 0o. Figure 4b illustrates the execution flow of the central service process from receiving a lock resource application to releasing the lock resource. As shown in Figure 4b, after resetting the lock flag area, the central service process can use polling to query the application flags of multiple client processes. Resetting the lock flag area may mean that all lock flag bits in the lock flag area are cleared. The central service process can determine whether any of the application flag bits of multiple client processes are set to 1. If multiple application flag bits are set to 1, the central service process can select a successful client process C from among the client processes corresponding to the multiple application flag bits set to 1 according to a predetermined scheduling algorithm and mark C as having successfully acquired the lock. Upon marking C as having successfully acquired the lock, the central service process can set the status flag corresponding to C to 1.Afterwards, the central service process can query whether C's release flag is set to 1. If C's release flag is set to 1, C is marked as having successfully released the lock. Upon marking C's release as successful, the central service process can set C's corresponding status flag to 0. If C's release flag is set to 0, the central service process can continue to query C's release flag until it reaches 1. As shown in Figure 4b, after marking C's release as successful, the central service process can continue to poll the application flags of multiple client processes to allocate lock resources for newly initiated lock resource requests. Figure 5a illustrates the state machine for the three lock flags of a client process. The three lock flags of any client process have four valid states: A, B, C, and D, with E and F being invalid states. As shown in Figure 5a, state A is the idle state. In this state, the application flag is 0, the release flag is X, and the status flag is 0. State B indicates that the client process holds the lock. In this state, the client process can access the shared target resource object. As shown in Figure 5a, in state B, the application flag is 0, the release flag is X, and the status flag is 1. State C is the state in which the client process applies to release the lock. In this state, the application flag is 0, the release flag is 1, and the status flag is 1. State D is the state in which the client process applies to grab the lock and waits to acquire the lock. In this state, the application flag is 1, the release flag is 0, and the status flag is 0. State E is an illegal state. In this state, the application flag is 1, the release flag is 1, and the status flag is 0. State F is an illegal state. In this state, the application flag is 1, the release flag is 1, and the status flag is 1. The above four valid state transition conditions are shown in Figure 5b. When a client process initiates a lock grabbing operation, the state machine transitions from state A to state D. When the client process enters a critical section to access the target resource object, the state machine transitions from state D to state B. When the client process completes the operation and requests to release the lock, the state machine transitions from state B to state C. When the central service process clears the completion status flag, the state machine transitions from state C to state A. The following, with reference to Figures 6a to 6f, illustrates the lock grabbing process for any two client processes. As shown in Figure 6a, when client process 1 and client process 2 simultaneously initiate lock grabbing requests to central service process 3, both the request flag of client process 1 and the request flag of client process 2 are set to 1.Central service process 3 can detect lock grabbing requests from client process 1 and client process 2. As shown in Figure 6b, after arbitrating multiple lock grabbing requests, central service process 3 determines that client process 1 has acquired the lock. Central service process 3 can determine that client process 1 has acquired the lock by setting the status flag bit of client process 1 to 0. Client process 1 can then determine that it has acquired the lock based on the value of its corresponding status flag bit. At this point, client process 2, which has not yet acquired the lock, can continuously poll its own status flag bit. As shown in Figure 6c, after completing the shared resource access operation, client process 1 can initiate a lock release request. Client process 1 can set its corresponding release flag bit to 0. Upon querying the release flag bit corresponding to client process 1, central service process 3 can determine that client process 1's lock release request has been detected. As shown in Figure 6d, central service process 3 can clear client process 1's status flag bit to 0 to complete the lock release. As shown in Figure 6e, after detecting the lock grabbing request from client process 2, central service process 3 can determine that client process 2 has acquired the lock based on the value of its corresponding status flag bit. As shown in Figure 6f, after client process 2 completes the shared resource access operation, it can initiate a lock release request. Client process 2 can set its corresponding release marker position to 1. Central service process 3, upon querying the release marker position corresponding to client process 2, can determine that client process 2's lock release request has been detected. Based on the above implementation, multiple client processes can implement distributed locks through shared memory without relying on Ethernet. Figure 7a is a flow chart of a distributed lock processing method provided by an embodiment of the present disclosure. This method is applied to any client process on any server in a distributed system. The multiple servers in the distributed system are interconnected via a target interconnect bus to a shared memory module. The shared memory module maintains lock marker areas corresponding to multiple client processes on the multiple servers that need to share a target resource object. As shown in Figure 7a, the method includes: Step 701a: Performing a write operation on the lock marker area corresponding to any client process in the shared memory module via the target interconnect bus to request a target lock from a lock resource management object. The lock resource management object is responsible for allocating the target lock and overwriting the lock marker area corresponding to the client process allocated the target lock. Step 702a: Read the lock mark area corresponding to any client process in the shared memory module via the target interconnect bus to check whether the target lock has been applied for. Step 703a: If the target lock has been applied for, access the target resource object. The target lock corresponds to the target resource object.In an optional embodiment, performing a write operation on a lock tag area corresponding to any client process in a shared memory module via a target interconnect bus to apply for a target lock from a lock resource management object includes: writing a first value to the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to apply for the target lock from the lock resource management object; correspondingly, performing a read operation on the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to query whether the target lock has been applied for, includes: reading the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to determine whether a third value exists in the lock tag area; if the third value exists, determining that the target lock has been applied for; if the third value does not exist, determining that the target lock has not been applied for. In an optional embodiment, the lock tag area corresponding to any client process includes an application flag bit and a status flag bit. Based on this, writing a first value into a lock flag area corresponding to any client process in a shared memory module via a target interconnect bus to apply for a target lock from a lock resource management object includes: setting an application flag position corresponding to any client process in the shared memory module to the first value via the target interconnect bus to apply for the target lock from the lock resource management object. Accordingly, performing a read operation on the lock flag area corresponding to any client process in the shared memory module via the target interconnect bus to determine whether a third value exists in the lock flag area includes: reading a status flag corresponding to any client process in the shared memory module via the target interconnect bus to determine whether the status flag is the third value. Furthermore, in an optional embodiment, before setting the request flag bit corresponding to any client process in the shared memory module to the first value via the target interconnect bus, the method further includes: reading the status flag bit corresponding to any client process in the shared memory module via the target interconnect bus to determine whether the status flag bit is a third value; if the status flag bit is a fourth value, executing an operation of setting the request flag bit corresponding to any client process in the shared memory module to the first value via the target interconnect bus; if the status flag bit is the third value, continuously reading the status flag bit via the target interconnect bus until the status flag bit is set to the fourth value. Furthermore, optionally, the lock flag area corresponding to any client process also includes a release flag bit. Based on this, if the target lock is applied for, the method further includes: setting the release flag bit corresponding to any client process in the shared memory module to a fifth value via the target interconnect bus to release the target lock; wherein, when the target lock is released, the request flag bit corresponding to any client process is set to the second value.Further optionally, during the process of releasing the target lock, the method further includes: setting the application mark position corresponding to any client process in the shared memory module to a second value via a target interconnect bus to release the target lock. In an optional embodiment, the method further includes: sending a request to share the target lock to the lock resource management object, so that the lock resource management object creates a lock mark area corresponding to any client process in the shared memory module and returns the location information of the lock mark area; receiving the location information of the lock mark area returned by the lock resource management object, and performing read and write operations on the lock mark area based on the location information of the lock mark area. Figure 7b is a flow diagram of another distributed lock processing method provided by an embodiment of the present disclosure. This method is applied to a lock resource management object in a distributed system. Multiple servers in the distributed system are interconnected to a shared memory module via a target interconnect bus. The shared memory module maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share the target resource object. As shown in Figure 7b, the method includes: Step 701b, performing a read operation on the lock flag areas corresponding to multiple client processes in the shared memory module to query whether a client process has applied for a target lock, the target lock corresponding to a target resource object. Step 702b, if a client process has applied for the target lock, determining a target client process from the client processes that have applied for the target lock. Step 703b, rewriting the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. In an optional embodiment, performing a read operation on the lock flag areas corresponding to multiple client processes in the shared memory module to query whether a client process has applied for the target lock includes: performing a read operation on the lock flag areas corresponding to multiple client processes in the shared memory module to determine whether a lock flag area containing a first value exists; if a lock flag area containing the first value exists, determining that a client process has applied for the target lock; if a lock flag area containing the first value does not exist, determining that a client process has applied for the target lock. Accordingly, rewriting the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process includes writing a third value into the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. In an optional embodiment, the lock flag area includes an application flag bit and a status flag bit.Based on this, a read operation is performed on lock tag areas corresponding to multiple client processes in a shared memory module to determine whether a lock tag area containing a first value exists. This operation includes: reading the request flag bits corresponding to the multiple client processes in the shared memory module to determine whether a request flag bit with the first value exists. Accordingly, a third value is written to the lock tag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. This operation includes: setting the status flag bit corresponding to the target client process in the shared memory module to the third value to assign the target lock to the target client process. In an optional embodiment, each lock tag area further includes a release flag bit. Based on this, the method further includes: reading the release flag bit corresponding to the target client process in the shared memory module, and if the release flag bit is a fifth value, setting the status flag bit corresponding to the target client process to a fourth value to reclaim the target lock. The release flag bit is set to the fifth value when the target client process releases the target lock. Further optionally, during the process of reclaiming the target lock, the method further includes: setting the application mark position corresponding to the target client process to a second value, so that the target client process can reapply for the target lock. Further optionally, determining the target client process from the client processes that have applied for the target lock includes: randomly selecting a client process from the client processes that have applied for the target lock as the target client process; or selecting the target client process based on at least one of the waiting time for the lock, the number of lock applications, and the priority of the client process that has applied for the target lock. Further optionally, the method further includes: receiving a request from any client process to share the target lock; and, based on the request, creating a lock mark area corresponding to the client process in the shared memory module and returning the location information of the lock mark area to the client process, so that the client process can perform read and write operations on the lock mark area based on the location information of the lock mark area. The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated on here. It should be noted that the execution entity of each step of the method provided in the aforementioned embodiments can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 71a to 73a may be device A; for another example, the execution entity of steps 71a and 72a may be device A, and the execution entity of step 73a may be device B; and so on.In addition, some processes described in the above embodiments and accompanying figures include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation sequence numbers, such as 71a and 72a, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different messages, devices, modules, etc., and do not represent a sequential order or limit the "first" and "second" to different types. Figure 8a is a schematic structural diagram of an electronic device provided in an embodiment of the present disclosure. As shown in Figure 8a, the electronic device includes a shared memory module 81a and a hardware-implemented lock resource management component 82a. The shared memory module 81a is interconnected with multiple servers via a target interconnect bus and maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share target resource objects. The lock resource management component 82a has read and write permissions for the shared memory module 81a. The lock resource management component 82a can be implemented based on programmable hardware such as an FPGA (Field Programmable Gate Array) or a CPLD (Complex Programming Logic Device), or on a chip such as an ASIC (Application Specific Integrated Circuit), without limitation. Furthermore, the hardware implementation structure of the lock resource management component 82a is also not limited; any hardware implementation structure capable of implementing the logic described in the above-mentioned distributed lock processing method embodiment is applicable to the embodiments of the present disclosure. The embodiments of the present disclosure provide an implementation structure of the lock resource management component 82a, as shown in FIG8a , comprising a hardware-implemented read component 821a, a determination component 822a, and a write component 823a. The reading component 821a is responsible for performing a read operation on the lock mark area corresponding to multiple client processes in the shared memory module 81a to query whether there is a client process applying for a target lock corresponding to a target resource object, and providing the query result to the determining component 822a.If the query result provided by read component 821a indicates that a client process has applied for the target lock, determination component 822a determines a target client process from the client processes applying for the target lock and notifies write component 823a. Based on the notification from determination component 822a, write component 823a rewrites the lock flag area corresponding to the target client process in shared memory module 81a to assign the target lock to the target client process. In an optional embodiment, read component 821a performs a read operation on the lock flag areas corresponding to multiple client processes in shared memory module 81a by: performing a read operation on the lock flag areas corresponding to multiple client processes in shared memory module 81a to determine whether a lock flag area containing a first value exists; if a lock flag area containing the first value exists, determining that a client process has applied for the target lock; if a lock flag area containing the first value does not exist, determining that a client process has applied for the target lock. Accordingly, the write component 823a rewrites the lock flag area corresponding to the target client process in the shared memory module 81a by writing a third value into the lock flag area corresponding to the target client process in the shared memory module 81a, thereby allocating the target lock to the target client process. In an optional embodiment, each lock flag area includes an application flag bit and a status flag bit. Based on this, the read component 821a is specifically responsible for reading the application flag bits corresponding to multiple client processes in the shared memory module 81a to determine whether an application flag bit with a first value exists. If an application flag bit with the first value exists, it is determined that a client process has applied for the target lock. If an application flag bit with the first value does not exist, it is determined that no client process has applied for the target lock. Accordingly, the write component 823a is specifically responsible for changing the status flag position corresponding to the target client process in the shared memory module 81a to the third value, thereby allocating the target lock to the target client process. Further, optionally, each lock flag area also includes a release flag bit. Based on this, the read component 821a is further responsible for reading the release flag corresponding to the target client process in the shared memory module 81a and, if the release flag is at the fifth value, notifying the write component 823a to set the status flag corresponding to the target client process to the fourth value to reclaim the target lock. The release flag is set to the fifth value when the target client process releases the target lock. Furthermore, optionally, the write component 823a is further configured to set the application flag corresponding to the target client process to the second value during the process of reclaiming the target lock, allowing the target client process to apply for the target lock again.In an optional embodiment, determination component 822a is specifically configured to: randomly select a client process from among the client processes applying for the target lock as the target client process; or, select the target client process based on at least one of the following information: the waiting time for the lock, the number of lock applications, and the priority of the client process applying for the target lock. The detailed implementation and beneficial effects of each of the above components have been described in detail in the previous embodiments and will not be elaborated upon here. Figure 8b is a schematic diagram of the structure of another electronic device provided by an embodiment of the present disclosure. This electronic device can be implemented as a server in a distributed system, but is not limited to this. The electronic device is interconnected to a shared memory module via a target interconnect bus. The shared memory module maintains lock marking areas corresponding to multiple client processes on the multiple servers that need to share the target resource object. As shown in Figure 8b, the electronic device includes a memory 81b and a processor 82b. Memory 81b is configured to store computer programs, such as the program code corresponding to the client process in the above embodiments, and can also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, messages, images, videos, etc. Processor 82b is coupled to memory 81b and is configured to execute program code corresponding to the client process in memory 81b, to: write a lock tag area corresponding to any client process in the shared memory module via a target interconnect bus to apply for a target lock from the lock resource management object; wherein the lock resource management object is responsible for allocating the target lock and rewriting the lock tag area corresponding to the client process allocated to the target lock; read a lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to query whether the target lock has been applied for; and if the target lock has been applied for, access a target resource object, to which the target lock corresponds.In an optional embodiment, when processor 82b performs a write operation on the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to apply for a target lock from the lock resource management object, the operation includes: writing a first value to the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to apply for the target lock from the lock resource management object. Correspondingly, when processor 82b performs a read operation on the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to inquire whether the target lock has been applied for, the operation includes: reading the lock tag area corresponding to any client process in the shared memory module via the target interconnect bus to determine whether a third value exists in the lock tag area; if the third value exists, determining that the target lock has been applied for; if the third value does not exist, determining that the target lock has not been applied for. In an optional embodiment, the lock tag area corresponding to any client process includes an application flag bit and a status flag bit. Based on this, when processor 82b writes the first value to the lock flag area corresponding to any client process in the shared memory module via the target interconnect bus to apply for the target lock from the lock resource management object, the processor 82b performs the following operations: Setting the application flag bit corresponding to any client process in the shared memory module to the first value via the target interconnect bus to apply for the target lock from the lock resource management object. Accordingly, when processor 82b performs a read operation on the lock flag area corresponding to any client process in the shared memory module via the target interconnect bus to determine whether the lock flag area contains a third value, the processor 82b performs the following operations: Reading the status flag bit corresponding to any client process in the shared memory module via the target interconnect bus to determine whether the status flag bit is the third value. Furthermore, in an optional embodiment, before setting the request flag bit corresponding to any client process in the shared memory module to the first value via the target interconnect bus, the processor 82b is further configured to: read the status flag bit corresponding to any client process in the shared memory module via the target interconnect bus to determine whether the status flag bit is a third value; if the status flag bit is a fourth value, set the request flag bit corresponding to any client process in the shared memory module to the first value via the target interconnect bus; and if the status flag bit is the third value, continue reading the status flag bit via the target interconnect bus until the status flag bit is set to the fourth value. Furthermore, optionally, the lock flag area corresponding to any client process further includes a release flag bit.Based on this, when the target lock is successfully applied for, processor 82b is further configured to: set the release flag corresponding to any client process in the shared memory module to the fifth value via the target interconnect bus, thereby releasing the target lock; wherein, when the target lock is released, the application flag corresponding to any client process is set to the second value. Further, optionally, during the process of releasing the target lock, processor 82b is further configured to: set the application flag corresponding to any client process in the shared memory module to the second value via the target interconnect bus, thereby releasing the target lock. In an optional embodiment, processor 82b is further configured to: send a request to share the target lock to the lock resource management object, so that the lock resource management object creates a lock mark area corresponding to any client process in the shared memory module and returns the location information of the lock mark area; receive the location information of the lock mark area returned by the lock resource management object, and perform read and write operations on the lock mark area based on the location information of the lock mark area. Furthermore, as shown in Figure 8b , the electronic device also includes other components, such as a communication component 83b, a display 84b, a power supply component 85b, and an audio component 86b. Figure 8b only schematically illustrates some components and does not mean that the electronic device only includes the components shown in Figure 8b . Furthermore, the components within the dashed box in Figure 8b are optional, not required, and their specific selection depends on the product form factor of the electronic device. The electronic device of this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the electronic device of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed box in Figure 8b . If the electronic device of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed box in Figure 8b .In addition to the above-mentioned electronic devices, the embodiments of the present disclosure also provide another electronic device. This electronic device has the same or similar implementation structure as the electronic device shown in FIG8b and is therefore not shown in the figure. The difference between this electronic device and the electronic device shown in FIG8b is that the computer program in the memory 81b executed by the processor 82b is different. In this embodiment, the computer program stored in the memory 81b may be the program code corresponding to the central service process in the above-mentioned embodiment. The processor 82b executes the program code of the central service process stored in the memory 81b to implement the following: reading the lock mark area corresponding to multiple client processes in the shared memory module to query whether there is a client process that has applied for the target lock, and the target lock corresponds to the target resource object; if there is a client process that has applied for the target lock, determining the target client process from the client processes that have applied for the target lock; and rewriting the lock mark area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. In an optional embodiment, when processor 82b reads the lock flag areas corresponding to multiple client processes in the shared memory module to query whether a client process has applied for a target lock, the processor 82b may: read the lock flag areas corresponding to the multiple client processes in the shared memory module to determine whether a lock flag area containing a first value exists; if a lock flag area containing the first value exists, determining that a client process has applied for the target lock; if a lock flag area containing the first value does not exist, determining that a client process has not applied for the target lock. Accordingly, when processor 82b rewrites the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process, the processor 82b may: write a third value into the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process. In an optional embodiment, the lock flag area includes an application flag bit and a status flag bit. Based on this, when processor 82b reads the lock flag areas corresponding to multiple client processes in the shared memory module to determine whether a lock flag area containing the first value exists, the processor 82b includes: reading the request flag bits corresponding to the multiple client processes in the shared memory module to determine whether a request flag bit with the first value exists. Accordingly, when processor 82b writes the third value to the lock flag area corresponding to the target client process in the shared memory module to assign the target lock to the target client process, the processor 82b includes: setting the status flag bit corresponding to the target client process in the shared memory module to the third value to assign the target lock to the target client process.In an optional embodiment, each lock flag area also includes a release flag. Based on this, processor 82b is further configured to read the release flag corresponding to the target client process in the shared memory module and, if the release flag is at the fifth value, set the status flag corresponding to the target client process to the fourth value to reclaim the target lock. The release flag is set to the fifth value when the target client process releases the target lock. Furthermore, optionally, during the process of reclaiming the target lock, processor 82b is further configured to set the application flag corresponding to the target client process to the second value, allowing the target client process to reapply for the target lock. Furthermore, optionally, when determining the target client process from the client processes that have applied for the target lock, processor 82b may randomly select a client process from the client processes that have applied for the target lock as the target client process; or select the target client process based on at least one of the waiting time, number of lock applications, and priority of the client process that has applied for the target lock. Further, optionally, processor 82b is further configured to: receive a request from any client process requesting a shared target lock; based on the request, create a lock mark area corresponding to any client process in the shared memory module and return the location information of the lock mark area to any client process, so that any client process can perform read and write operations on the lock mark area based on the location information. The detailed implementation and beneficial effects of the above operations have been described in detail in the previous embodiments and will not be elaborated upon here. Accordingly, embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When the computer program is executed by processor 82b, it enables processor 82b to implement each step of the above method embodiments. Detailed descriptions of each step in each of the above method embodiments can be found in the previous embodiments and will not be repeated here. Accordingly, embodiments of the present disclosure also provide a computer program product containing a computer program / instructions. When the computer program / instructions is executed by processor 82b, it enables processor 82b to implement each step in the above method embodiments. Detailed descriptions of each step in each of the above method embodiments can be found in the previous embodiments and will not be repeated here.The aforementioned memory can be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a near-field communication (NFC) component to facilitate short-range communication. For example, the NFC component can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies. The aforementioned display includes a screen, which can include a liquid crystal display (LCD) and a touch panel (TP). OIf the screen includes a touch panel, it can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. The power supply assembly described above provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located. The audio assembly described above can be configured to output and / or input audio signals. For example, the audio assembly includes a microphone (MIC) that is configured to receive external audio signals when the device in which the audio assembly is located is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio assembly also includes a speaker configured to output audio signals. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process. The instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. oMemory is an example of computer-readable media. Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access 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 memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmitting medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements may include not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.Industrial Applicability: The solution provided in this disclosure can be applied to the distributed lock processing process. A bus protocol capable of providing shared memory and the shared memory it provides are introduced into the distributed lock application and release process. Multiple servers hosting client processes in a distributed system are interconnected with a shared memory module via an interconnect bus corresponding to the bus protocol capable of providing shared memory. A lock tag area corresponding to each client process is maintained in the shared memory module. The client process and the lock resource management object implement distributed lock application and release by performing read and write operations on the lock tag area in the shared memory module. The entire distributed lock application process no longer interacts via Ethernet, but rather via an interconnect bus supporting shared memory. Leveraging the advantages of bus transmission, this improves distributed lock application efficiency, reduces latency, and enhances the performance of distributed systems that rely on distributed locks.

Claims

22 Claims 1. A distributed lock processing method, applied to any client process on any server in a distributed system, wherein multiple servers in the distributed system are interconnected via a target interconnect bus to form a shared memory module, wherein the shared memory module maintains lock marking areas corresponding to multiple client processes on the multiple servers that need to share a target resource object. The method comprises: A write operation is performed on the lock mark area corresponding to the any client process in the shared memory module via the target interconnect bus to apply for a target lock from a lock resource management object; wherein the lock resource management object is responsible for allocating the target lock and rewriting the lock mark area corresponding to the client process allocated to the target lock; a read operation is performed on the lock mark area corresponding to the any client process in the shared memory module via the target interconnect bus to query whether the target lock is applied for; if the target lock is applied for, the target resource object is accessed, and the target lock corresponds to the target resource object.

2. The method according to claim 1, wherein: Performing a write operation on the lock mark area corresponding to the any one client process in the shared memory module through the target interconnect bus to apply for a target lock from the lock resource management object includes: writing a first value into the lock mark area corresponding to the any one client process in the shared memory module through the target interconnect bus to apply for a target lock from the lock resource management object; correspondingly, performing a read operation on the lock mark area corresponding to the any one client process in the shared memory module through the target interconnect bus to query whether the target lock has been applied for, including: performing a read operation on the lock mark area corresponding to the any one client process in the shared memory module through the target interconnect bus to determine whether a third value exists in the lock mark area; if the third value exists, determining that the target lock has been applied for; if the third value does not exist, determining that the target lock has not been applied for.

3. The method according to claim 2, wherein: The lock mark area corresponding to any one of the client processes includes: an application mark bit and a status mark bit; wherein, writing a first value into the lock mark area corresponding to any one of the client processes in the shared memory module through the target interconnection bus to apply for a target lock from the lock resource management object includes: setting the application mark position corresponding to any one of the client processes in the shared memory module to the first value through the target interconnection bus to apply for a target lock from the lock resource management object; wherein, performing a read operation on the lock mark area corresponding to any one of the client processes in the shared memory module through the target interconnection bus to determine whether a third value exists in the lock mark area includes: reading the status mark bit corresponding to any one of the client processes in the shared memory module through the target interconnection bus to determine whether the status mark bit is the third value.

4. The method according to claim 3, wherein: Before setting the application mark position corresponding to any client process in the shared memory module to the first value through the target interconnection bus, the method further includes: A status flag bit corresponding to any one of the client processes in the shared memory module is read through the target interconnect bus to determine whether the status flag bit is the third value; if the status flag bit is the fourth value, an operation is performed to set the application flag bit corresponding to any one of the client processes in the shared memory module to the first value through the target interconnect bus; and if the status flag bit is the third value, the status flag bit is continuously read through the target interconnect bus until the status flag bit is set to the fourth value.

5. The method according to claim 3, wherein: The lock mark area corresponding to any one of the client processes also includes: a release mark bit; in a case where the target lock is applied for, the method further includes: setting the release mark bit corresponding to the any one of the client processes in the shared memory module to a fifth value via the target interconnect bus to release the target lock; wherein, when the target lock is released, the application mark bit corresponding to the any one of the client processes is set to a second value.

6. The method according to any one of claims 1 to 5, wherein: Also includes: Sending a request for sharing the target lock to the lock resource management object, so that the lock resource management object creates a lock mark area corresponding to any client process in the shared memory module and returns location information of the lock mark area; The location information of the lock mark area returned by the lock resource management object is received, so as to perform a read and write operation on the lock mark area according to the location information of the lock mark area.

7. A distributed lock processing method, applied to a lock resource management object in a distributed system, wherein multiple servers in the distributed system are interconnected through a target interconnect bus to share a memory module, wherein the shared memory module maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share a target resource object, the method comprising: A read operation is performed on lock mark areas corresponding to the multiple client processes in the shared memory module to query whether there is a client process that has applied for a target lock, where the target lock corresponds to the target resource object; if there is a client process that has applied for the target lock, a target client process is determined from the client processes that have applied for the target lock; and a lock mark area corresponding to the target client process in the shared memory module is rewritten to allocate the target lock to the target client process.

8. The method according to claim 7, wherein: Performing a read operation on lock mark areas corresponding to the multiple client processes in the shared memory module to query whether there is a client process that has applied for a target lock, including: performing a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to determine whether there is a lock mark area containing a first value; if there is a lock mark area containing the first value, determining that there is a client process that has applied for the target lock; if there is no lock mark area containing the first value, determining that there is no client process that has applied for the target lock; and correspondingly, rewriting the lock mark area corresponding to the target client process in the shared memory module to allocate the target lock to the target client process, including: A third value is written into the lock mark area corresponding to the target client process in the shared memory module to allocate the target lock to the target client process.

9. The method according to claim 8, wherein: The lock mark area includes: an application mark bit and a status mark bit; wherein, performing a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to determine whether there is a lock mark area containing a first value includes: reading the application mark bits corresponding to the multiple client processes in the shared memory module to determine whether there is an application mark bit with the first value; wherein, writing a third value into the lock mark area corresponding to the target client process in the shared memory module to allocate the target lock to the target client process includes: setting the status mark position corresponding to the target client process in the shared memory module to the third value to allocate the target lock to the target client process.

10. The method according to claim 9, wherein: The lock mark area also includes: a release mark bit; the method also includes: reading the release mark bit corresponding to the target client process in the shared memory module, and when the release mark bit is a fifth value, setting the status mark position corresponding to the target client process to a fourth value to reclaim the target lock; wherein the release mark bit is set to the fifth value when the target client process releases the target lock.

11. A distributed system comprising: Multiple servers, a lock resource management object, and a shared memory module interconnected with the multiple servers via a target interconnect bus; Multiple client processes that need to share a target resource object are running on the multiple servers, and the shared memory module maintains lock mark areas corresponding to the multiple client processes. Any client process is configured to perform read and write operations on the lock mark area corresponding to it in the shared memory module through the target interconnection bus to apply for a target lock from the lock resource management object, and access the target resource object if the target lock is applied for. The lock resource management object is configured to read the lock mark areas corresponding to the multiple client processes in the shared memory module to allocate the target lock, and rewrite the lock mark area corresponding to the client process allocated to the target lock.

12. The system according to claim 11, wherein: The lock resource management object is a central service process running on a control device, and the control device is interconnected with the shared memory module via a target interconnection bus; or, the lock resource management object is a central service process running on the electronic device to which the shared memory module belongs; or, the lock resource management object is located on the electronic device to which the shared memory module belongs and is a lock resource management component implemented based on hardware.

13. An electronic device, comprising: Shared memory module and lock resource management component; The shared memory module 25 is interconnected with multiple servers via a target interconnection bus, and maintains lock mark areas corresponding to multiple client processes on the multiple servers that need to share a target resource object; wherein the lock resource management component includes: a read component, a determination component, and a write component implemented based on hardware; the read component is responsible for performing a read operation on the lock mark areas corresponding to the multiple client processes in the shared memory module to query whether there is a client process that has applied for a target lock, the target lock corresponding to the target resource object, and providing the query result to the determination component; if the query result provided by the read component indicates that there is a client process that has applied for the target lock, the determination component determines a target client process from the client processes that have applied for the target lock and notifies the write component; the write component rewrites the lock mark area corresponding to the target client process in the shared memory module according to the notification of the determination component to allocate the target lock to the target client process.

14. An electronic device, comprising: memory and processor; The memory is configured to store a computer program, and the processor is coupled to the memory and configured to execute the computer program to implement the steps in the method according to any one of claims 1 to 10.

15. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 1 to 10.

16. A program product comprising a computer program / instructions, which, when executed by a processor, causes the processor to implement the steps of the method according to any one of claims 1 to 10.

Images