Method for managing lock in cluster, lock server and client

Abstract

Provided is a solution for managing a lock in a cluster. The cluster comprises a client and a lock server. The lock server contains an interface card and a memory. The memory stores a read lock request queue and records an identifier of a client in a read lock waiting state or obtains a read lock, and the memory further stores a write lock request queue and records an identifier of a client in a write lock waiting state or obtains a write lock. The memory further contains a read lock allocation count and a write lock allocation identifier, wherein the former is used to record an allocated read lock, and the latter is used to represent whether a write lock has already been allocated. The client communicates with the interface card of the lock server via an RDMA protocol, so as to perform a lock operation.

Description

technical field [0001] The invention relates to the field of information technology, in particular to a method for lock management in a cluster, a server and a client. Background technique [0002] There are multiple clients in the cluster. In order to obtain the processing permission of shared resources in the cluster, such as write permission or read permission, a client needs to apply for processing permission from the lock server in the cluster, which is usually called applying for a lock. Usually write permission is also called write lock, or exclusive lock, and read permission is called read lock or shared lock. [0003] As shown in FIG. 1 , the prior art client applies for a write lock, and the cluster includes a lock server, client A, and client B. Client A writes the identity of client A to the memory address of the lock server using the Remote Direct Memory Access (RDMA) protocol, such as using the atomic operation Compare-and-Swap in the RDMA protocol to apply fo...

AI Technical Summary

Problems solved by technology

[0004] In the implementation scheme of the existing technology, client A fails, because the lock server does not know that client B is in the write lock waiting state, so client B cannot apply for the write lock, and is always in the write lock waiting state

As can be seen from the above description, the lock server in the prior art can only obtain the lock status of the current client

Images