CN115878514A - Lock management method and device, computing equipment and distributed system - Google Patents

Abstract

A lock management method, a device, a computing device and a distributed system are provided, wherein the method comprises the following steps: a network card of a first computing device acquires a lock access request for applying for executing access operation on a first lock, wherein the first lock is used for controlling the access authority of a first shared resource; and the network card responds to the lock access request and triggers the access operation of the first lock. By the method, the unloading processing of the lock management operation executed by the CPU of the first computing device can be realized, the network card executes the lock management control, the processing operation of the CPU is reduced, and the utilization rate of the CPU is improved. In addition, the network card can directly obtain the lock access request or generate the lock access request according to the data processing request, the CPU is not needed to respond to the lock access request, the calculation cost of the CPU is reduced, and the first lock is stored in the first memory of the network card, the network card does not need to access the lock across buses, so that the lock access request can be directly completed in the network card, and the response delay of the lock access request is reduced.

Description

Lock management method and device, computing equipment and distributed system

Technical Field

The present application relates to the field of computer technologies, and in particular, to a lock management method and apparatus, a computing device, and a distributed system.

Background

A lock is a basic control mechanism that enables ordered access to the same shared resource by multiple objects, which may be multiple computing devices within the same distributed system, or multiple processes (or multiple threads) within the same computing device.

Currently, one lock-based data access process is: the method comprises the steps that a corresponding lock is set for each shared resource, an accessor can access the shared resources only by acquiring the lock, and the lock is released after the access is finished, so that the plurality of accessors can access the shared resources orderly.

Taking a distributed system as an example, assuming that the distributed system includes a first computing device and a second computing device, before the second computing device initiates access to a certain shared resource on the first computing device, a lock access request for obtaining a lock corresponding to the shared resource may be first sent to the first computing device, the first computing device receives the lock access request through a network card, and sends the lock access request to a processor of the first computing device through the network card, and then the processor executes an application operation for the lock, and the lock release operation is also the same process, which is not described herein again. The above operation not only occupies more computing resources, network and I/O resources of the processor, but also the processing speed of the processor affects the data processing request, so that the whole data processing request cannot meet the high-performance service requirement.

Disclosure of Invention

The application provides a lock management method, a lock management device, a computing device and a distributed system, which are used for shortening response time delay to a lock access request on the basis of reducing processing operation of a CPU.

In a first aspect, an embodiment of the present application provides a lock management method, which may be applied to a first computing device, where the first computing device includes a network card and a processor, and the network card is further provided with a first memory. In the method, a network card may receive a lock access request, where the lock access request is used to apply for executing a specified access operation (e.g., lock applying operation or lock releasing operation) on a specified lock (e.g., a first lock), where the first lock is used to control an access right of a first shared resource, and the first lock is stored in a first memory of the network card; the network card triggers an access operation to a first lock in the first memory in response to the lock access request.

By the method, the lock management control is executed by the network card for unloading the lock management operation executed by the CPU of the first computing device, so that the processing operation of the CPU is reduced, and the utilization rate of the CPU is improved. On the other hand, the network card may directly obtain the lock access request through the communication interface or generate the lock access request according to the data processing request, and the CPU is not required to respond to the lock access request, so that the computational overhead of the CPU is reduced, and in addition, if the lock requested to be accessed by the lock access request is located in the storage 1142 of the network card 114, because the first storage 1142 and the lock control module 1141 are directly connected, the lock control module 1141 does not need to access the lock across the bus, so that the lock access request from the client 10 may be directly completed in the network card 114, thereby reducing the time delay of the server 20 responding to the lock access request, and reducing the congestion pressure of the access operation on the lock between the network card 114 and the memory 113.

In a possible implementation manner, before the network card acquires the lock access request, a lock storage policy may be determined according to an available storage space of a first memory of the network card; exemplary latch storage strategies include: a full offload policy and a partial offload policy, wherein the full offload policy is to complete a management operation on a full lock managed by a processor of the first computing device; the partial offload policy is used to complete a management operation on a partial lock managed by a processor of the first computing device (e.g., a first set of locks including at least one of a full lock managed by the processor).

By the method, the management operation of all locks managed by the processor can be unloaded to the network card for execution by executing the full unloading strategy, so that the computing resources of the processor can be further released, and the utilization rate of the processor is improved; and executing a partial unloading strategy, unloading the management operation of partial locks managed by the processor to the network card for execution, balancing the load conditions of the processor and the network card, and ensuring the stable operation of the network card on the basis of reducing the calculation load of the processor.

In one possible embodiment, all locks managed by the processor may be stored in the second memory, and when it is determined that the available storage space of the first memory is greater than the first threshold, a full offload policy may be performed that stores all locks managed by the processor of the first computing device in the first memory, i.e., stores all locks in the second memory in the first memory, and at this time, no locks are in the second memory. When the available storage space of the first memory is not larger than the second threshold, a partial unload policy may be performed, i.e., storing the first lock set in the first memory, i.e., storing any lock belonging to the first lock set in the second memory into the first memory.

By the method, the full unloading strategy is executed, and all locks managed by the processor can be stored in the first memory of the network card, so that for the network card, the locks requested to be accessed by any received lock access request are stored in the network card, the time for determining the storage positions of the locks and the calculation cost are saved, the network card does not need to access the locks across buses, and the time delay of the server 20 responding to the lock access request is reduced. And a partial unloading strategy is executed, so that the storage load of the first storage can be relieved, and the requirement on the hardware capacity of the first storage is reduced.

In one possible implementation, when at least one lock is stored in both the first memory and the second memory of the first computing device, the network card may also control the migration of one or more locks in the second memory to the first memory. For example, the network card determines a second lock set in the second memory according to the frequency of the accessed locks, each lock in the second lock set is migrated to the first memory, and the first lock is any lock in the second lock set.

By the method, the network card can dynamically control the lock to migrate between the first memory and the second memory, for example, when the lock in the second memory is migrated to the first memory, the storage burden of the second memory can be reduced, and further based on the dynamic migration of the lock, the network card can store the lock accessed at high frequency in the first memory as much as possible, so that the response time delay of the network card to the lock access request is shortened, and the traffic and congestion pressure of the network card accessing the lock in the second memory across buses are reduced.

In one possible implementation, the processor determines a third set of locks stored in the first memory based on a frequency with which the locks are accessed, and migrates each lock in the third set of locks from the first memory to the second memory.

By the method, the processor can transfer the lock stored in the first memory to the second memory, the storage load of the first memory can be reduced, and the processor can store the lock accessed by the processor with high frequency as much as possible in the second memory based on the dynamic transfer of the lock, so that the response time delay of the processor to the lock access request is shortened.

In one possible implementation, the way for the network card to acquire the lock access request may include: the network card receives a lock access request sent by second computing equipment; or, the network card receives a lock access request sent by a processor of the first computing device; or the network card executive program calls the request to generate a lock access request.

In one possible implementation, the network card and the processor are connected by a multi-protocol interconnect bus.

By the method, the multi-protocol interconnection bus supports various semantics, so that various data transmission requirements between the network card and the processor can be met through one protocol bus, and the flexibility and the convenience of lock migration are provided.

In one possible implementation, the network card and the processor may be connected by PCIe.

In one possible implementation, the first shared resource is located in a second memory of the first computing device, the second memory including a plurality of shared resources, the first shared resource being any one of the plurality of shared resources; or the first shared resource is stored in the second computing device, and the latch corresponding to the first shared resource is stored in the first computing device.

In a second aspect, an embodiment of the present application further provides a lock management device, where the lock management device has a function of implementing a behavior in the method example of the first aspect, and for beneficial effects, reference may be made to description of the first aspect, which is not described herein again. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above. In a possible design, the structure of the lock management apparatus includes an obtaining module and a processing module, and these modules may execute corresponding functions in the method example of the first aspect, for which specific reference is made to detailed description in the method example, and details are not described here.

In a third aspect, an embodiment of the present application further provides a lock management device, where the lock management device has a function of implementing a behavior in the method example of the first aspect, and for beneficial effects, reference may be made to description of the first aspect, which is not described herein again. The device comprises a processor, a memory and optionally a communication interface. The processor is configured to support the lock management device to perform corresponding functions in the method of the first aspect. The memory is coupled to the processor and retains computer program instructions and data (e.g., at least one lock) necessary for the communication device. The structure of the lock management device also comprises a communication interface which is used for communicating with other equipment, such as receiving a lock access request.

In a fourth aspect, an embodiment of the present application further provides a computing device, where the computing device includes a lock management apparatus, and the lock management apparatus has a function of implementing a behavior in the method example of the first aspect, and beneficial effects may be seen in descriptions of the first aspect and are not described herein again.

In a fifth aspect, the present application further provides a computer-readable storage medium having stored therein instructions, which, when executed on a computer, cause the computer to perform the method described in the first aspect and the various possible implementations of the first aspect.

In a sixth aspect, the present application further provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect and the various possible implementations of the first aspect.

In a seventh aspect, the present application further provides a computer chip, where the chip is connected to a memory, and the chip is configured to read and execute a software program stored in the memory, and perform the method described in the first aspect and each possible implementation manner of the first aspect.

In an eighth aspect, an embodiment of the present application further provides a distributed system, where the distributed system includes a first computing device and a second computing device, and the second computing device is configured to send a lock access request to the first computing device; the lock access request is used for applying for executing access operation on a first lock, and the first lock is used for controlling the access authority of the first shared resource; the first lock is stored in a memory of a network card of the first computing device; the lock management apparatus of the first computing device has a function of implementing the behavior in the method example of the first aspect, and for beneficial effects, reference may be made to the description of the first aspect, which is not described herein again.

The present application can further combine to provide more implementations on the basis of the implementations provided by the above aspects.

Drawings

FIG. 1 is a diagram of an access scenario for a lock;

fig. 2 is a schematic diagram of a distributed system architecture according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of a computing device according to an embodiment of the present application;

fig. 4 is a schematic flowchart of a lock management method according to an embodiment of the present application;

FIG. 5 is a block diagram illustrating an architecture of a lock according to the lock management method of the present application;

FIG. 6 is a schematic diagram of another lock management method according to an embodiment of the present disclosure;

FIG. 7 is a schematic diagram of another structure to which a lock is applied according to the lock management method provided in the embodiment of the present application;

fig. 8 is a schematic structural diagram of a lock management device provided in the present application.

Detailed Description

To facilitate understanding of the method of lock management provided by the embodiments of the present application, first, concepts and terms related to the embodiments of the present application will be briefly described.

1) A shared resource, a resource that can be shared by a plurality of objects, such as data that is allowed to be allocated to a plurality of objects for sharing or a storage space in which the data is located, may be referred to as a shared resource, and each of the plurality of objects may initiate an access operation, such as reading or writing, on the shared data. Where multiple objects may refer to multiple processes or multiple threads in the same computer device. Or the multiple objects may be different devices in the same communication system.

When a plurality of objects initiate access operations to the same shared resource, a lock is usually used to control ordered access of the plurality of objects to the shared resource, and only one object is allowed to perform access operations to the same shared resource at the same time, so as to avoid the problem of data inconsistency.

2) Locks, which are concepts corresponding to shared resources, may be configured with one lock for each shared resource, and the lock is used to control the access right of its corresponding shared resource.

Referring to FIG. 1, each object needs to acquire a lock before accessing the shared resource before it can access the shared resource. After any object acquires the lock, the state of the lock is in a locked state, and at the moment, the shared resource can only be accessed by the object acquiring the lock. And releasing the lock after the object obtaining the lock completes the access of the shared resource, wherein the lock state is in an unlocked state, and other objects can initiate a new round of lock obtaining competition, so that the ordered access of a plurality of objects to the same shared resource is realized.

Common locks include spin locks and read-write locks.

A read-write lock: one shared resource can correspond to a group of read-write locks, including a read lock and a write lock, where the read lock is used to indicate that multiple objects can obtain the lock at the same time, that is, multiple objects are allowed to read the shared resource corresponding to the same lock at the same time, and an object applying for the read lock may also be referred to as a reader; write lock is a lock that allows only one object to acquire at a time, and an object applying for write lock may also be referred to as a write lock.

Self-rotating lock: a shared resource can correspond to a spin lock, the spin lock does not distinguish a read lock from a write lock, namely the spin lock does not distinguish whether the type of an operation request of an object is a read operation or a write operation, namely the object applying the spin lock does not distinguish a reader from a writer, and at the moment, the reader and the writer can share one lock.

In a specific implementation process, the lock can be realized through a memory variable, specifically, a value of the memory variable is used for representing a state of the lock, taking a read-write lock as an example, in a group of read-write locks, if the length of the write lock is 1bit, when the value of the 1bit indicates 1, the write lock can be represented to be in a locked state; when the value of the 1bit indicates 0, it may indicate that the write lock is in an unlocked state. Similar to write locks, read locks may also represent different read lock states by having different contents indicated by the values of the memory variables. For example, if the status information of the read lock includes 4 bytes, the 4 bytes may be used to record a situation that a plurality of objects obtain the read lock, and specifically may include information such as an identifier of each object. Of course, besides using different values of the memory variable to indicate different states of the read lock and the write lock, the lock state of the spin lock may also be recorded by using a similar method, which is not described herein again for brevity. In addition, the lengths of the various locks listed above are only examples, and the embodiments of the present application do not limit the types of locks and the lengths of the locks.

3) Atomic operation refers to a set of operations of minimum granularity, indivisible, and unbreakable by interval, where the set includes two or more operations. Atomic operations are not interrupted by other types of operations (e.g., parallel operations), and only one atomic operation ends can the execution of the other operations begin. Exemplary atomic operations may include computer-supported packed instruction level operations (e.g., compare And Swap (CAS), fetch And Add (FAAD), read operations, write operations, etc.), and atomic operations that bundle multiple instruction level operations, such as packing a read-modify-write back into one atomic operation.

When the state of the lock is implemented using memory variables, the atomic operations on the memory variables of the lock include CAS, FAAD, or other atomic operations such as read-modify-write back packed atomic operations. For example, the lock may be obtained using a read-modify-write back atomic operation to update the value of the write lock's memory variable from 0 (e.g., to indicate an unlocked state) to 1 (e.g., to indicate a locked state).

4) The process may refer to a single operation activity of a program having an independent function, and is a carrier for running the application program, or may be understood as a process that is a running instance of the application program and is a single dynamic execution of the application program. The process is an independent unit for resource allocation and scheduling of the system, each process is allocated with an accessible memory space, and different processes are independent of each other.

5) Threads, the same process comprising one or more threads, multiple threads contained in a single process supporting concurrent execution of different tasks, multiple threads may share resources of the process (e.g., memory space accessible to the process).

6) The multi-protocol interconnect bus refers to a dynamic interconnect technology bus supporting multiple protocols, such as a Z-Generation (GENZ) bus or a compute express link (CXL) bus, which can provide access protocols between multiple processors and components at the same time, and semantics of the access protocols can be enabled wholly or partially. By way of example, the semantics supported by the multi-protocol interconnect bus include, but are not limited to:

i) Cache (caching) semantics: a device (device) cache (e.g., a cache in the network card 114) in the host is allowed to obtain data from a memory (e.g., the memory 113) of the host processor connected to the device, and the host processor uses cache-snoop (cache detect) messages to manage data consistency of the device cache. The host may be any computing device in fig. 1, such as the server 20, and the device may be any component in the server 20, such as the network card 114 of the server 20 shown in fig. 2.

ii) memory access protocol: allowing the host processor to directly access the device memory in a cache coherent manner. For example, after the data in the device memory is updated, the device can synchronously update the updated data in the device memory to the processor memory based on the consistency principle of the memory access protocol.

iii) Input/output (I/O) semantics: similar to peripheral component interconnect express (PCIe), I/O semantics having properties including, but not limited to: device discovery, configuration, initialization, I/O virtualization, and Direct Memory Access (DMA)/atomic operation, etc.).

Hereinafter, the application of the multi-protocol interconnect bus will be described by taking the above semantics as an example, but the application of the multi-protocol interconnect bus to the embodiments of the present application is not meant to include other types of semantics, and the multi-protocol interconnect bus to the embodiments of the present application is not meant to be limited to the above semantics.

7) A distributed system is a system composed of a plurality of independent nodes (e.g., servers, processing units, etc.) which are geographically and physically distributed.

The management method provided by the present application is described in detail below with reference to the accompanying drawings.

Fig. 2 is a schematic architecture diagram of a distributed system according to an embodiment of the present disclosure. The system includes one or more clients 10 (three clients 10 are shown in fig. 3, but not limited to three clients 10) and a server 20.

The client 10 may be software or a service of a computing device deployed on a user side, where the computing device includes a device with computing capability, such as a server, a desktop computer, a notebook computer, or a mobile terminal. A user may send a data request, such as a write data request for requesting a write operation to a shared resource, or a read data request for requesting a read operation to a shared resource, or a lock access request for applying for a lock or releasing a lock, to the server 20 through the client 10.

The server 20 may be a device having both computing and storage capabilities, such as a server, desktop computer, or the like. The server 20 may be used to provide services to the client 10, such as providing storage and computing resources to the client 10. Illustratively, the server 20 may be configured to store a shared resource associated with a lock requested by a plurality of clients 10 and a lock corresponding to the shared resource.

Fig. 2 illustrates an example in which the client 10 is a desktop computer and the server 20 is a server, and in fact, the specific form of the client 10 and the server 20 is not limited in the embodiment of the present application. Client 10 and server 20 may communicate over network 150. The network 150 may be wired or wireless communication. By way of example, network 150 generally represents any telecommunications or computer network, including, for example, an intranet, a Wide Area Network (WAN), a Local Area Network (LAN), a Personal Area Network (PAN), the Internet, or a wireless network (e.g., WIFI, 5 th generation (5 th generation) (5H) ^th Generation, 5G) communication technology). In particular, the client 10 may communicate with the server 20 using a variety of network protocols, such as TCP/IP, UDP/IP, RDMA, and the like. Client 10 and server 20 in addition to passing through the above-described example of network 150, client 10 may also communicate with server 20 through a fabric switch. Alternatively, the fabric switch may be replaced with an ethernet switch, an InfiniBand switch, a converged ethernet based remote direct memory access (RDMA over converted ethernet, roCE) switch, or the like.

Further, fig. 3 is a schematic structural diagram of the server 20 according to the embodiment of the present disclosure, and as shown in the figure, the server 20 at least includes a processor 112, a memory 113, and a network card 114. The processor 112, the memory 113 and the network card 114 are connected by a bus 115.

The processor 112 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), an Artificial Intelligence (AI) chip, a system on chip (SoC) or a Complex Programmable Logic Device (CPLD), a Graphic Processing Unit (GPU), a neural Network Processing Unit (NPU), or the like.

The memory 113 is an internal memory directly exchanging data with the processor 112, and can read and write data at any time, and is fast, and serves as a temporary data storage for an operating system or other programs in operation. In the embodiment of the present application, the memory 113 stores one or more shared resources, and optionally, the memory 113 may also be used to store locks of the shared resources.

The memory 113 includes at least two types of memory, for example, the memory 113 may be a random access memory (ram) or a Read Only Memory (ROM). For example, the random access memory is a Dynamic Random Access Memory (DRAM), or a Storage Class Memory (SCM). DRAM is a semiconductor memory, and, like most of the RAM, belongs to a volatile memory (volatile memory) device. SCM is a hybrid storage technology that combines the features of both traditional storage devices and memory, memory-class memory providing faster read and write speeds than hard disks, but slower access speeds and lower cost than DRAM. However, the DRAM and the SCM are only exemplary in the embodiments of the present application, and the memory may also include other random access memories, such as Static Random Access Memory (SRAM), and the like. The rom may be, for example, a Programmable Read Only Memory (PROM), an Erasable Programmable Read Only Memory (EPROM), and the like. In addition, the memory 113 may also be a dual in-line memory module (DIMM), or a dual in-line memory module (DIMM), i.e., a module composed of DRAMs. In practical applications, the server 20 may be configured with a plurality of memories 113 and different types of memories 113. The number and type of the memories 113 are not limited in this embodiment.

And a network card 114 for communicating with the components inside the client 10 or the server 20. In the present application, the network card 114 has a computing capability, and can be used for processing data access requests (such as lock access requests) from outside the server 20 (such as the client 10) and also for processing lock access requests generated inside the server 20.

In hardware, the network card 114 includes a lock control module 1141, a memory 1142 and a communication interface 1143, and optionally, the network card 114 may further include an accelerator 1144, since the accelerator 1144 is an optional component, it is shown by a dashed box in fig. 4. Lock control module 1141, memory 1142, communication interface 1143, and accelerator 1144 may be connected via a bus.

It should be noted that lock control module 1141 (also referred to as a lock control engine) may be implemented as a hardware logic circuit, a processing core, an ASIC, an AI chip, or a Programmable Logic Device (PLD), and the PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), a system on chip (SoC), or any combination thereof. Alternatively, lock control module 1141 may be a software module, or a combination of a software module and a hardware module.

The lock control module 1141 may communicate with the client 10 via the communication interface 1143, or with other components (e.g., the processor 112 or the acceleration device 1144) in the server 20, such as receiving a lock access request sent by the client 10 or the acceleration device 1144 via the communication interface 1143. Lock control module 1141 may operate the lock management method provided in the embodiments of the present application, for example, lock control module 1141 responds to the lock access request to trigger the lock access operation.

Memory 1142 is an internal memory capable of directly exchanging data with lock control module 1141, and is capable of reading and writing data at any time, and is fast in speed, and is used as a temporary data memory for a program running on lock control module 1141. The hardware components of memory 1142 are similar to memory 113, as described above with reference to memory 113. In this application, the memory 1142 may be a memory particle embedded in the network card 114, and the memory 1142 and the lock control module 1141 may be connected by a DDR bus, that is, the memory 1142 and the lock control module 1141 are directly connected.

Memory 1142 may be used to store some or all locks on server 20 in this application. It is noted that if locks are stored in both memory 113 and storage 1142, then the locks stored in memory 113 and storage 1142 are different. The lock in the memory 113 and the lock in the storage 1142 have a one-to-one mapping relationship with the shared resource, that is, one lock only corresponds to one shared resource. Illustratively, the mapping includes an identification of the lock (e.g., a memory address of the lock) and an identification of the shared resource (e.g., a memory address of the shared resource). It should be noted that the shared resource corresponding to the lock stored in the memory 113 is not limited to the shared resource stored in the server 20, such as the shared resource stored in other computing devices, such as the client 10, for example, the shared resource 1 is stored in the client 10, and the lock corresponding to the shared resource 1 is stored in the server 20. Similarly, the shared resource corresponding to the lock in the storage 1142 may be a shared resource stored in the server 20, or may also be a shared resource stored in another device, such as the client 10, which is not limited in this embodiment of the application.

Optionally, the lock control module 1141 may also be used to maintain stored information (hereinafter, referred to as "lock stored information") of a partial lock or a full lock on the server 20, for example, the partial lock may be a lock in the storage 1142, and the full lock includes a lock in the storage 1142 and a lock in the memory 113. Illustratively, the lock storage information includes a lock identification and a storage location of the lock (e.g., the storage location is used to indicate whether the lock is located in the memory 1142 or the memory 113, or the storage location is a storage address locked in the memory 113 or the memory 1142), etc. After receiving the lock access request, lock control module 1141 may determine whether the lock requested to be accessed by the lock access request is located in memory 113 or storage 1142 according to the lock storage information.

In an alternative embodiment of the present application, the processor 112 may also include a module having the same function as the lock control module 1141, such as the lock control module 1121, and the lock control module 1121 of the processor 112 and the lock control module 1141 of the network card 114 may have the same function and the same form, except that, for example, the lock control module 1121 of the processor 112 is configured to respond to a lock access request generated by the processor 112 or required to be processed by the processor 112, and the lock control module 1141 is configured to respond to a lock access request generated by the network card 114 or received by the network card 114.

The acceleration device 1144 may be used to execute an uninstall program for operations or functions performed by the processor 112, for example, the acceleration device 1144 may implement a Remote Procedure Call (RPC) to uninstall the functions of the processor 112. In this application, the acceleration device 1144 may interact with the client 10 through the communication interface 1143, for example, the acceleration device 1144 may receive a data processing request sent by the client 10 through the communication interface 1143, and if the data processing request is used to request to access a specified shared resource, the acceleration device 1144 may analyze the obtained data processing request, determine the shared resource requested to be accessed by the data processing request, and determine a lock corresponding to the shared resource according to the mapping relationship between the lock and the shared resource, thereby generating the lock access request. Accelerator 1144 may interact with lock control module 1141 via communication interface 1143, e.g., accelerator 1144 sends the generated lock access request to lock control module 1141.

The bus 115 includes, but is not limited to: a PCIe bus, a Double Data Rate (DDR) bus, an interconnect bus supporting multiple protocols (hereinafter, referred to as a multi-protocol interconnect bus, which will be described in detail), a Serial Advanced Technology Attachment (SATA) bus, a Serial Attached SCSI (SAS) bus, a Controller Area Network bus (CAN), a computer standard Connection (CXL) standard bus, and the like.

For example, the processor 112 and the memory 113 may be connected by a DDR bus, and the processor 112 and the network card 114 may be connected by, but not limited to: a multi-protocol interconnect bus connection or a PCIe bus connection. The service end of the embodiment of the present application does not limit the bus protocol used between the components, and any connection manner or communication protocol that enables communication between the components is applicable to the embodiment of the present application.

It should be noted that the structure of the server 20 shown in fig. 3 is only an example, in an actual product, the server 20 or the network card 114 may have more or less components, for example, the server 20 may further include an input/output device such as a keyboard, a mouse, and a display, and a hard disk, such as a non-volatile memory (non-volatile memory), for example, a ROM, a Hard Disk Drive (HDD) or a Solid State Drive (SSD), and the like. For another example, the network card 114 may also include the aforementioned hard disk. The embodiment of the present application does not limit the specific structures of the server 20 and the network card 114.

Next, a lock management method provided in an embodiment of the present application will be described with reference to fig. 4, taking the system shown in fig. 2 as an example. For convenience of description, the following embodiments of the present application are described by taking the lock control module 1141 of the server 20 to execute the lock management method provided in the embodiments of the present application as an example.

Referring to fig. 4, fig. 4 is a schematic flowchart of a lock management method provided in an embodiment of the present application, and as shown in fig. 4, the method includes the following steps:

step 400a: initialization is performed based on a latch storage policy.

The lock storage policy may be determined from the available storage space of memory 1142 during an initialization phase.

In the embodiment of the application, the latch storage strategy comprises a full unloading strategy and a partial unloading strategy. Where the full offload policy is used to complete management of all locks in server 20, where all locks include the locks managed by processor 112. The partial offload policy is used to perform a management operation on a partial lock managed by the processor (e.g., a first set of locks), where the first set of locks includes one or more locks. Locks managed by processor 112 may be understood to include locks stored in memory 113.

The specific process of the execution flow is described as follows, taking the lock control module 1141 executing the latch storage policy as an example:

lock control module 1141 may determine the lock storage policy based on the available storage space of memory 1142. For example, when the available storage space of the storage 1142 is greater than a set threshold (e.g., referred to as a first threshold), the full offload policy is executed, that is, when the available storage space of the storage 1142 is greater than the first threshold, the lock control module 1141 may store all locks in the storage 113 in the storage 1142. When the available storage space of the memory 1142 is less than or equal to the second threshold, the partial offload policy is executed. That is, when the available storage space of the storage 1142 is less than or equal to the second threshold, the lock control module 1141 stores the lock belonging to the first lock set in the storage 113 into the storage 1142.

The first threshold may be determined according to the size of the memory space occupied by all the locks on the server 20, for example, the first threshold may be greater than or equal to the size of the memory space occupied by all the locks on the server 20. The second threshold may be determined according to the first threshold, and the first threshold and the second threshold may be the same or different, for example, the second threshold may be a value smaller than or equal to the first threshold, which is not limited in this application. It should be noted that the first threshold and the second threshold may also be determined empirically or through testing or service requirements (for example, lock processing latency or lock processing efficiency) in combination with a specific product, which is not limited in this embodiment of the present application.

The lock storage policy may be executed by the lock control module 1141 at the initialization stage of the server 20, or executed by other components, such as the processor 112, or executed by the lock control module 1121 in fig. 5, or may be configured by a user, for example, the user introduces all locks on the server 20 into the memory 1142, so as to save the calculation overhead of executing the lock storage policy by the components of the server 20, which is not limited in this application.

It should be noted that step 400 is an optional step, and is not a necessary step, for example, in the case that the user has stored all the locks of the server 20 in the memory 1142, the components of the server 20 may not execute the lock storage policy repeatedly, and thus is shown by the dashed box in fig. 6.

Step 401: the lock control module 1141 obtains the lock access request.

The lock access request is used to request that an access operation be performed on a specified lock (e.g., a first lock). Illustratively, the lock access request includes a lock identification of the first lock and information indicating an application for an access operation to be performed on the first lock. This information may be, for example, an opcode, with different opcodes indicating different types of access operations. For example, access operations to a lock include an apply lock operation and a release lock operation. When the value of the operation code is 1, the access operation is the lock application operation, and when the value of the operation code is 0, the access operation is the lock release operation. It will be appreciated that the application lock operates to acquire the lock and the release lock operates to release the lock.

As will be understood from fig. 1 and fig. 2, if the lock access request may be sent by the client 10, and if the lock access request may be sent by the processor 112, or the lock access request may also be generated by the accelerator 1144, for example, the accelerator 1144 receives a data processing request from the client 10, and if the data processing request is used to request to access the shared resource, the accelerator 1144 may generate a lock access request for a lock corresponding to the shared resource to be accessed based on the data processing request (see step 400 b), and send the lock access request to the lock control module 1141. It should be noted that step 400b is an optional step, and is not a step that has to be performed, and is therefore shown as a dashed box. It should be noted that, the steps 400a and 400b are not strictly limited in time sequence, and the step 400b may be before the step 400a, after the step 400a, or simultaneously occur in the steps 400a and 400b, which is not limited in this embodiment of the present application.

In the present application, lock access requests may be divided into near-end requests and far-end requests based on the source of the lock access request.

Wherein the near-end request and the far-end request are both relative to the lock control module. For example, as understood in connection with fig. 2, for the lock control module 1141 disposed in the network card 114, the near-end request includes a lock access request received by the network card 114 from the client 10 or a lock access request generated by the acceleration device 1144 on the network card 114, and the far-end request includes a lock access request sent by a component, such as the processor 112, in the server 20. It will be appreciated that the near-end request is sent to lock control module 1141 from the assembly of network card 114 that is relatively close to lock control module 1141, and the far-end request is sent to lock control module 1141 from processor 112 that is relatively far from lock control module 1141.

For another example, for the lock control module 1121 disposed in the processor 112, the near-end request includes a lock access request sent by the processor 112, and the far-end request includes a lock access request sent by the lock control module 1141 through the bus.

Similarly, the storage location of the lock requested to be accessed for the lock access request may separate the lock into a local lock and a remote lock.

Wherein the local lock and the remote lock are also relative to the lock control module. For example, for lock control module 1141 disposed in network card 114, the local lock includes a lock that lock control module 1141 may directly access, such as a lock located in memory 1142; the remote lock includes a lock that lock control module 1141 needs to access across the bus, such as a lock located in memory 113. By cross-bus, it is meant that the access path needs to go through at least two buses, for example, the access path of lock control module 1141 to the lock in memory 113 includes the bus between lock control module 1141 and processor 112 and the bus between processor 112 and memory 113.

For another example, for lock control module 1121 disposed in processor 112, the local lock comprises a lock in memory 113 and the remote lock comprises a lock in storage 1142.

For convenience of description, in the following description, the local lock and the remote lock are both for the same lock that the lock control module can directly access, for example, the local lock is requested to access the local lock by the near-end request received by lock control module 1141, where the local lock is the local lock of lock control module 1141 (i.e., the lock in memory 1142), or the remote request received by lock control module 1141 is requested to access the local lock, and the local lock is also the lock managed by the network card where lock control module 1141 is located, i.e., the lock stored in memory 1142 of network card 14. The near-end request received by lock control module 1141 requests access to a remote lock, which is the remote lock of lock control module 1141 (i.e., the lock in memory 113).

In an alternative embodiment, the lock control module 1141 may count lock access records based on the received lock access request, for example, including but not limited to one or more of the following: frequency of near-end requests to access the local lock, frequency of near-end requests to access the far-end lock, and frequency of far-end requests to access the local lock. Referring to table 1 below, table 1 is a specific example of a lock access record generated by lock control module 1141.

TABLE 1 Lock Access records

For example, if it is assumed that, in a period of time, the Lock control module 1141 receives a near-end request 1 sent by the client 10 and a near-end request 2 sent by the acceleration device 1144, where both the near-end request 1 and the near-end request 2 are used to request to access the Lock _ a, the Lock control module 1141 records that the frequency of the Lock _ a being accessed by the near-end request is 2.

It should be noted that the lock access record may further include other information, such as the number of times the remote cache is intercepted, access time, a source of the lock access request, and the like, which is not limited in this embodiment of the present application. In addition, the values of the access frequency and the lock identifier shown in table 1 are only for illustration to keep brevity and are not intended to limit the practical application of the present application.

Subsequently, lock control module 1141 may execute a lock migration policy according to the lock access record, for example, migrate a remote lock frequently accessed by the near-end request to memory 1142, so that the remote lock becomes a local lock of lock control module 1141, thereby shortening the time delay of the lock access request. As will be described in detail below.

Step 402: the lock control module 1141, in response to the lock access request, triggers an access operation to the lock (first lock) requested to be accessed by the lock access request.

In the present application, it is assumed that a first lock is stored in memory 1142 and that lock control module 1141 triggers an access operation to the first lock in memory 1142. For example, if the lock access request is for acquiring a lock, the lock control module 1141 triggers a lock application operation on the first lock. If the lock access request is for a release of the lock, the lock control module 1141 triggers a release of the lock operation for the first lock.

In particular, a lock application operation often includes an atomic operation composed of multiple operations, such as a CAS, an atomic operation packed read-modify-write back, and so on. Taking CAS as an example, the CAS switching process has three stages V, O and N, wherein V represents an actual value stored in a target memory; o represents an expected value, i.e., a value used for comparison with V, the expected value is an expected value stored in an expected destination memory, and the expected value can be exchanged only when the expected value is the expected value, and in this application, the expected value is a value indicating that the lock is in an unlocked state; n represents the new value, i.e. the value of V ready to be updated. After the CAS is executed, if V is equal to O, the expected value is equal to the actual value in the memory, which means that no thread modifies the value again after the last modification, so N can be replaced in the destination memory, i.e. N is used to replace V. And if V is not equal to O, the value in the target memory is modified by other threads, so that N cannot be replaced, and execution failure is returned. When multiple threads operate on a variable using the same CAS, only one thread will succeed and successfully update the variable value, and all other threads will fail. The failing thread may retry or suspend (block) the thread.

As described above, the read-write lock includes read-write and write locks, and here, taking obtaining the write lock as an example, the value of the memory variable of the write lock is given as 1 to indicate that the write lock is in a locked state; a value of 0 indicates that the write lock is in an unlocked state. At this time, the memory space where the memory variable of the write lock is located is the destination memory, and when the memory variable of the write lock is operated by using the CAS to obtain the write lock, O =0 and n =1 are carried, the process of obtaining the write lock may include: and acquiring a value stored in the target memory, namely V, comparing the acquired V with O, and if V = O =0, indicating that the write lock is in an unlocked state, replacing the value of N (1) in the target memory so as to acquire the write lock. If V ≠ O, i.e. V =1, it indicates that the write lock is in a locked state, and cannot be replaced, and the lock application fails. When the access is complete, the lock is released by the object that obtained the lock, such as by sending a write data request to request that the memory variable of the lock be written to 0.

It should be noted that the CAS is only an example, and any access operation that can be performed on a lock is applicable to the embodiment of the present application.

In the mode, the lock management operation executed by the CPU is unloaded, the network card directly executes the lock management control, the processing operation of the CPU is reduced, and the utilization rate of the CPU is improved. On the other hand, the network card may directly obtain the lock access request through the communication interface or generate the lock access request according to the data processing request, and the lock access request does not need to be forwarded to the CPU and then the CPU responds to the lock access request, thereby reducing the computational overhead of the CPU, and in addition, if the lock requested to be accessed by the lock access request is located in the storage 1142 of the network card 114, because the storage 1142 and the lock control module 1141 are directly connected, the lock control module 1141 does not need to access the lock across the bus, thus, the lock access request from the client 10 may be directly completed in the network card 114, thereby reducing the time delay of the server 20 responding to the lock access request, and reducing the congestion pressure of the access operation on the lock between the network card 114 and the memory 113.

The following describes the lock management method provided in the embodiment of the present application in detail with reference to specific embodiments.

In the first embodiment, all locks of the server 20 are stored in the memory 1142 of the server 20.

Fig. 5 is a hardware architecture of the server 20 determined on the basis of fig. 3, as shown in fig. 5, a lock control module 1141 and an accelerator 1144 are disposed in the network card 114, and all locks of the server 20 are stored in a memory 1142 of the network card 114.

In the first embodiment, the latch storage policy in the initialization phase may be executed, and it can be seen that the server 20 shown in fig. 5, which is executed in the initialization phase, is an all-offload policy, that is, it is determined that the available storage space of the storage 1142 is less than or equal to the second threshold, and then a part of the latch is reserved in the memory 113. Alternatively, the lock storage policy in the initialization stage may not be executed, for example, all locks are imported into the memory 1142 through user configuration, which is described in detail with reference to step 400 and is not described herein again.

The process that the server 20 shown in fig. 5 may execute to implement the lock management method of the present application includes:

(1) The lock control module 1141 obtains the lock access request, and the obtaining way is described in relation to step 401, and is not described herein again.

(2) After receiving the lock access request, in fig. 5, because all locks of the server 20 are stored in the memory 1142, the lock control module 1141 does not need to determine a storage location of the lock to be accessed, and directly initiates an access operation on the lock to be accessed in the memory 1142.

In the above manner, since the locks on the server 20 are all stored in the memory 1142, for the lock control module 1141, the locks requested to be accessed by any received lock access request are all local locks, which saves time and calculation overhead for determining the storage location of the locks, and does not need to access the locks across buses, thereby shortening the response time delay of the lock control module 1141 to any received lock access request.

In the second embodiment, the storage 1142 and the memory 113 respectively store partial locks.

Fig. 6 is another hardware architecture of the server 20 determined on the basis of fig. 3, as shown in fig. 6, a lock control module 1141 and an accelerator 1144 are disposed in the network card 114, and a memory 1142 and a memory 113 of the network card 114 store partial locks respectively. It will be appreciated that the locks in storage 1142 and memory 113 are different.

In the second embodiment, the latch storage policy in the initialization phase may be executed, and it can be seen that the server 20 shown in fig. 6, which is executed in the initialization phase, is a partial offload policy, that is, it is determined that the available storage space of the storage 1142 is less than or equal to the second threshold, and then a partial latch is reserved in the memory 113. Alternatively, the latch storing strategy in the initialization stage may not be executed, so that a part of the latches are stored in the memory 113 and the rest of the latches are stored in the memory 1142.

The process that the server 20 shown in fig. 6 may execute to implement the lock management method of the present application includes:

(1) The way for the lock control module 1141 to obtain the lock access request is described in step 401, and is not described herein again.

(2) The lock control module 1141 triggers an access operation to the lock to be accessed in response to the lock access request.

Since the lock to be accessed may be located in memory 113 and may also be located in storage 1142, the lock to be accessed may be a local lock or a remote lock. The lock control module 1141 has the following scenarios for different types of lock access requests (near-end request or far-end request) and different types of locks requested for access (local lock or far-end lock):

scenario one, the near end request requests access to the local lock.

If the first lock is a local lock (i.e., stored in memory 1142), the lock control module 1141 may directly initiate an access operation to the first lock in memory 1142.

First, a manner of determining the local lock and the remote lock is described: lock control module 1141 determines the storage location of the first lock based on the lock identifier (such as the first lock) carried in the lock access request and the aforementioned lock storage information, and if the first lock is located in memory 113, it is a remote lock; if the first lock is located in memory 1142, the first lock is a local lock. The lock control module 1141 may determine whether the lock access request is a near-end request or a far-end request based on the source of the lock access request, which is described above and will not be repeated here.

Scenario two, the near end requests access to the far end lock.

If the first lock is a remote lock (i.e. stored in the memory 113), the lock control module 1141 has a plurality of processing manners, which may specifically adopt any one of the following processing manners:

the first processing mode is as follows: if the first lock is a remote lock, the first lock may be migrated from the remote (the memory 113) to the local (the memory 1142) to be a local lock, and then the lock control module 1141 triggers an access operation on the first lock in the memory 1142, so as to avoid accessing the first lock across the bus and shorten the access delay.

Example 1, the migration flow may include: based on the lock access record, lock control module 1141 determines whether the remote lock satisfies the immigration condition, and if so, lock control module 1141 migrates the remote lock from memory 113 to memory 1142; otherwise, the migration is not performed (please refer to the step of processing mode two in the following process, which is not described herein again).

Immigration conditions include, but are not limited to: the frequency with which the near-end requests access to the far-end lock exceeds a certain threshold (e.g., referred to as a third threshold). Taking table 1 as an example, assuming that the third threshold is 20 and the first Lock is Lock _ h, it can be determined based on table 1 that the frequency (29) of the near-end request to access the Lock _ h is greater than the third threshold (20), and it is determined that Lock _ h satisfies the immigration condition, and Lock control module 1141 immigrates Lock _ h from memory 113 to storage 1142. For another example, assuming that the first Lock is Lock _ y, it can be determined based on table 1 that the frequency (5) of the near-end request to access the Lock _ y is not greater than the third threshold (20), and the Lock _ y is not migrated.

Similarly, in an alternative embodiment, lock control module 1141 may also migrate the local lock satisfying the migration condition in storage 1142 from storage 1142 to memory 113. Exemplary, emigration conditions include, but are not limited to: the frequency of access requests by the remote to access the local lock exceeds a certain threshold (e.g., a fourth threshold). Or the access frequency of the remote end request for accessing the local lock exceeds the fourth threshold and is higher than the access frequency of the near end request for accessing the local lock. Or, the access frequency of the remote request for accessing the local lock is higher than that of the near-end request for accessing the local lock, or the number of times that the remote cache listens to the local lock exceeds a certain threshold (e.g., a fifth threshold), and so on. Illustratively, lock control module 1141 may determine the migration timing according to the usage of storage 1142, for example, when the usage of storage 1142 exceeds a certain threshold (sixth threshold), the lock satisfying the migration condition in storage 1142 is migrated to memory 113.

Example 2, the immigration process may include: lock control module 1141 may not execute the above-mentioned determination logic, and directly migrate the remote lock to be accessed to the local memory (i.e., storage 1142), that is, no matter whether the remote lock satisfies the migration condition, when the lock to be accessed by lock control module 1141 is not in storage 1142, lock control module 1141 may migrate the remote lock to the local memory, and then trigger the access operation on the lock in storage 1142, so as to shorten the access delay.

The second processing mode: if the first lock is a remote lock, the lock control module 1141 may not perform the lock migration operation, and directly trigger the access operation to the first lock in the memory 113.

Illustratively, lock control module 1141 is not used to control dynamic migration of the lock, that is, the first lock is not migrated to the memory of the network card, lock control module 1141 sends an access operation request for the first lock to a processing unit corresponding to processor 112 through a bus with processor 112, where the processing unit may be used to execute an access operation for the first lock in memory 113, and the processing unit executes an access operation for the first lock in memory 113 through the bus between processor 112 and memory 113.

And in the third scenario, the remote end requests to access the local lock.

In one embodiment, taking the remote request as an example, which is sent to the lock control module 1141 by the processor 112, the process includes: processor 112 determines the storage location of the lock requested to be accessed by the lock access request, and if the lock is located in memory 113, the control/arithmetic unit of processor 112 may also be configured to trigger an access operation to the lock in memory 113 in response to the lock access request, in which case processor 112 does not send the lock access request to lock control module 1141. If the lock requested to be accessed is located in the memory 1142, the processor 112 sends the lock access request to the lock control module 1141, and correspondingly, the lock control module 1141 receives the lock access request sent by the processor 112, where the lock access request is a remote request for the lock control module 1141, and since the processor 112 has determined the storage location of the over-lock, the lock control module 1141 may default that the lock requested to be accessed by the lock access request is located in the memory 1142 when receiving the lock access request sent by the processor 112, and the lock control module 1141 triggers an access operation on the lock in the memory 1142. In this manner, if the processor 112 determines the storage location of the lock, the lock control module 1141 does not need to determine the storage location again, thereby reducing the computational burden of the lock control module 1141.

In another optional embodiment, lock control module 1141 may further determine a storage location of the lock requested to be accessed in the lock access request, and trigger a corresponding access operation according to the storage location of the lock, see the foregoing related description, and are not described herein again.

As a possible embodiment, in addition to the lock migration policy triggered based on the lock access request mentioned above, the present application provides another lock migration policy. For example, lock control module 1141 may predict one or more remote locks to be accessed and migrate the predicted remote locks to local storage 1142 in advance, which may further reduce lock access latency relative to the manner in which remote locks are migrated locally after receiving a lock access request. For example, lock control module 1141 may predict locks that may be accessed in the future based on characteristics of locks accessed over a continuous historical period of time. For example, lock B is typically accessed after lock A is accessed, and lock B is a remote lock, then lock B may be migrated from memory 113 to storage 1142 in advance after receiving a lock access request requesting access to lock A. For another example, if the time at which the lock is accessed is periodically regular, the lock to be accessed may be predicted based on the temporal characteristics. Or the prediction can be performed in other manners, and the prediction algorithm is not limited in the embodiment of the present application. By the method, the remote lock can be migrated to the local memory in advance, so that the response delay of the lock access request is further shortened.

The specific manner of lock migration is described as follows:

the first migration mode: if the network card 114 and the processor 112 are connected through the multi-protocol interconnect bus in the server 20 shown in fig. 6, lock migration may be implemented through the multi-protocol interconnect bus.

1) Lock control module 1141 migrates the remote lock to memory 1142;

for the introduction of the multi-protocol interconnect bus, reference is made to the foregoing explanation, which is not repeated herein. In this application, lock control module 1121 may migrate locks in memory 113 to storage 1142 through a memory access protocol of a multi-protocol interconnect bus.

2) Lock control module 1141 migrates the local lock to memory 113;

in this application, the lock control module 1141 may migrate, through a caching semantic of the multiprotocol interconnection bus, a lock in a cache of the network card 114 (e.g., a lock cache in the network card 114 in fig. 7) to a cache of the processor (e.g., a lock cache in the processor 112 in fig. 7) based on a synchronization mechanism of the cache semantic, and then the processor 112 writes the lock in the lock cache into the memory 113. The lock cache in the processor 112 may be an L1/L2/L3 cache of the processor 112, or may be an independent cache, which is not limited in this embodiment of the present application.

In this application, when the lock control module 1141 triggers an access operation on a remote lock, the triggered access operation on the lock in the storage 1142 may also be sent to the lock control module 1121 or sent to the memory 113 via the processor 112 through the I/O semantics of the multi-protocol interconnection bus.

In the above manner, since the multi-protocol interconnection bus supports multiple semantics, multiple data transmission requirements between the network card 114 and the processor 112 can be satisfied by one protocol bus, and flexibility and convenience of lock migration are provided.

And (2) a second migration mode: in the server 20 shown in fig. 6, if the network card 114 and the processor 112 are connected by a PCIe bus, the lock migration may be implemented by the PCIe bus.

1) Lock control module 1141 migrates the remote lock to memory 1142;

illustratively, lock control module 1141 determines a remote lock (e.g., lock n) satisfying the immigration condition, and lock control module 1141 reads lock n in memory 113 through PCIe semantics and stores the read lock n in memory 1142, and updates the storage address of lock n to point to the storage address of lock n in memory 1142. And lock control module 1141 sends second indication information to processor 112 indicating that lock n is invalid in memory 113 and the address where lock n is stored in memory 1142. The processor 112 updates the memory address of the lock n according to the second indication information.

2) Lock control module 1141 migrates the local lock to memory 113;

further exemplarily, taking lock control module 1141 as an example, lock control module 1141 determines a local lock (for example, lock m) satisfying the immigration condition, and lock control module 1141 writes lock m into memory 113 through PCIe semantics, and sends first indication information to processor 112, where the first indication information is used to indicate that lock m is located in a storage address of memory 113. Processor 112 updates the storage address of lock m according to the first indication information, and lock control module 1141 also updates the storage address of lock m to the storage address of memory 113 for lock m.

However, the above manner of implementing lock migration through a multi-protocol interconnect bus or a PCIe bus is only an example, and in this embodiment, the network card 114 and the processor 112 may also implement lock migration through other bus connections, which is limited in this embodiment of the present application.

Based on the design in the second embodiment, a part of the locks may be stored in the memory 113, which may relieve the storage burden of the storage 1142 and reduce the hardware requirement on the storage 1142. Further, the dynamic migration of the lock is performed, and the lock accessed by the lock control module 1141 at high frequency is stored in the corresponding local storage 1142 as much as possible, so that the time delay of the lock control module 1141 responding to the lock access request is shortened, and the flow and congestion pressure of the cross-bus access lock are reduced.

In the third embodiment, the memory 113 and the storage 1142 respectively store part of the locks, and the lock control module 1121 is disposed in the processor 112.

Fig. 7 is a hardware architecture of a third server 20 determined on the basis of fig. 3, and as shown in fig. 7, a third embodiment includes the following features in common with the second embodiment: the network card 114 is provided with a lock control module 1141 and an accelerator 1144, and the memory 1142 and the memory 113 store partial locks respectively, wherein the locks in the memory 1142 and the memory 113 are different. The third embodiment is different from the second embodiment in that in the third embodiment, a lock control module 1121 is disposed in the processor 112. Lock control module 1121 has the same function as lock control module 1141 in network card 114, such as executing a lock storage policy, executing a lock migration policy, responding to a lock access request, triggering an access operation to a lock, and the like. The operation performed by the lock control module 1141 in the third embodiment is the same as the lock control module 1141 in the second embodiment, and the description is not repeated here, and only the operation performed by the lock control module 1121 is described below.

In the third embodiment, the latch storage policy in the initialization phase is executed, and it can be seen that the server 20 shown in fig. 7 executes a partial offload policy in the initialization phase. Alternatively, the latch storing strategy in the initialization stage may not be executed, so that a part of the latches are stored in the memory 113 and the rest of the latches are stored in the memory 1142.

The process that the server 20 shown in fig. 7 may execute to implement the lock management method of the present application includes:

(1) The lock control module 1121 obtains a lock access request. The lock access request may be sent by network card 114 to lock control module 1121, or may be sent by processor 112 to lock control module 1121.

For the lock control module 1121, the near-end request includes a lock access request sent by the processor 112, and the far-end request includes a lock access request from the network card 114. The local locks include locks in memory 113 and the remote locks include locks in storage 1142. Similarly, the lock control module 1121 may count lock access records according to the lock access request received by itself, and the lock access records may refer to the above description, which is not described herein again.

Subsequently, the lock control module 1121 may control the migration of the lock according to the self-counted lock access records. For example, lock control module 1121 may migrate a remote lock (i.e., a lock located in storage 1142) that satisfies the immigration condition to a local memory (i.e., memory 113), thereby reducing the latency of lock control module 1121 in responding to a lock access request. For example, immigration conditions include, but are not limited to: the frequency with which the near-end requests access to the far-end lock exceeds a certain threshold (e.g., referred to as a seventh threshold). The seventh threshold may be the same as or different from the third threshold in the immigration condition determined by lock control module 1141, which is not limited in this embodiment of the application. Optionally, lock control module 1121 may also determine local locks in memory 113 that satisfy the migration condition, and migrate these local locks from memory 113 to storage 1142. The migration condition can be referred to the related description of the migration condition on the lock control module 1141 side, and is not described herein again. The threshold values of lock control module 1121 and the emigration condition followed by lock control module 1141 may be the same or different, and this is not limited in this embodiment of the application.

Similarly, the lock control module 1121 may perform different response modes to the lock access request according to the type of the received lock access request (i.e., the near-end request or the far-end request) and whether the lock to be accessed is a local lock or a far-end lock, for example, if the lock access request is a near-end request with respect to the lock control module 1121 and the lock to be accessed is a local lock (i.e., located in the memory 113), the lock control module 1121 initiates an access operation on the lock. For another example, if the lock access request is a near-end request and the lock to be accessed is a far-end lock, the lock control module may migrate the far-end lock to the lock cache of the processor 112 in a manner similar to the first and second middle lock control modules 1141, then write the lock in the lock cache of the processor 112 into the memory 113, and the lock control module 1121 triggers an access operation on the lock in the memory 113, or maintains the lock to be accessed to be stored in the storage 1142, that is, does not migrate, and the lock control module 1121 sends the access operation on the lock to the lock control module 1141, and the lock control module 1141 completes the access operation on the lock in the storage 1142. For a specific migration manner, please refer to the related description in the second embodiment, and the description is not repeated here.

Based on the design of the third embodiment, lock control module 1121 may actively migrate locks from storage 1142 to memory 113, thereby reducing the burden of storage 1142. Lock control module 1141 may also actively transfer the lock from memory 113 to storage 1142, and further implement bidirectional transfer of the lock between memory 113 and storage 1142 on the basis of the second embodiment, so as to improve the hit rate of storage 1142 and memory 113, and at the same time, reduce the time delay of lock control module 1121 in responding to the lock access request.

It should be noted that, in the first to third embodiments, the accelerator 1144 is an optional component, that is, in fig. 4 to fig. 6, the network card 114 may not be provided with the accelerator 1144, and the difference from the setting of the accelerator 1144 is that the sources of the lock control module 1141 for obtaining the lock access request are reduced, and the manner of responding to the lock access request by the lock control module 1141 may be unchanged, which is referred to the above description and is not repeated herein. If the network card 114 receives the data processing request sent by the client 10, the network card 114 may send the data processing request to the processor 112, and the processor 112 generates a lock access request, that is, the processor 112 executes the function of the acceleration device 1144, and then the processor 112 may directly send the lock access request to the lock control module 1141. The method for managing the lock provided by the embodiment of the present invention is described in detail above with reference to fig. 1 to 7, and the lock management device provided by the embodiment of the present invention is described below with reference to fig. 8.

Fig. 8 is a schematic structural diagram of a lock management device 800 provided in the present application, and as shown in the figure, the lock management device 800 includes a request obtaining module 801, a processing module 802, and a first storage module 803. The lock management device 800 is used for executing the method executed by the network card 114 in the above method embodiments. The obtaining module 801 may be configured to execute the method executed by the communication interface 1143, and the processing module 802 may be configured to execute the method executed by the lock control module 1141.

An obtaining module 801, configured to obtain a lock access request, where the lock access request is used to apply for performing an access operation on a first lock, and the first lock is used to control an access right of a first shared resource; the first lock is stored in the first storage module 803; for a specific implementation, please refer to the description of step 401 in fig. 4, or the related descriptions of the first to third embodiments, which are not repeated herein.

The processing module 802 is configured to trigger an access operation on a first lock in response to a lock access request. For a specific implementation, please refer to the description of step 402 in fig. 4, or the related descriptions of the first embodiment to the third embodiment, which are not repeated herein.

It should be understood that the lock management device 800 according to the embodiment of the present invention may be implemented by a Central Processing Unit (CPU), an application-specific integrated circuit (ASIC), or a Programmable Logic Device (PLD), where the PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. When the lock management methods shown in fig. 4 to 7 can be implemented by software, the lock management apparatus 800 and the modules thereof may also be software modules.

Optionally, the processing module 802 is further configured to determine a latch storage policy according to the available storage space of the first storage module 803; the latch storage strategy comprises: a full offload policy and a partial offload policy, the full offload policy to complete a management operation of a full lock managed by a processor of the first computing device; the partial offload policy is used to complete a management operation of a first set of locks managed by a processor of the first computing device, the first set of locks including at least one of the full locks managed by the processor. For a specific implementation, please refer to the description of step 400a in fig. 4, or the related description of the first embodiment to the third embodiment, which is not repeated herein.

Optionally, the full offload policy includes: when the available storage space of the first storage module 803 is greater than a first threshold, all latches managed by the processor of the first computing device are stored in the first storage module 803; the partial unloading comprises: when the available storage space of the first storage module 803 is not greater than the second threshold, the first lock set is stored in the first storage module 803. For a specific implementation, please refer to the description of step 400a in fig. 4, or the related descriptions of the first to third embodiments, which are not repeated herein.

Optionally, the first lock is stored in a second memory of the first computing device; the processing module 802 is further configured to: at least one lock in the second memory is migrated to the first memory, the at least one lock including the first lock.

For example, when the processing module 802 migrates at least one lock in the second memory to the first memory, the following is specifically performed: and determining a second lock set in the second storage module according to the access frequency of the locks, and migrating each lock in the second lock set to the first storage module 803, wherein the first lock is any lock in the second lock set. For a specific implementation, please refer to the description of step 401 in fig. 4, or the related descriptions of the first to third embodiments, which are not repeated herein.

As a possible implementation manner, the present application further provides a lock management device, which may be the network card 114 shown in fig. 3, and is configured to implement the relevant method steps to implement the method executed by the lock control module 1141 in the foregoing embodiment, refer to descriptions of steps 400a to 402 in fig. 4, or relevant descriptions of the first to third embodiments, which are not described herein again.

As a possible implementation manner, the present application further provides a computing device, where the computing device includes the network card 114 shown in fig. 3, and the network card 114 is configured to implement the relevant method steps to implement the method executed by the lock control module 1141 in the foregoing embodiment, refer to descriptions of steps 400a to 402 in fig. 4, or relevant descriptions of the first embodiment to the third embodiment, which are not described again here.

As a possible implementation manner, an embodiment of the present application further provides a computer storage medium, where the computer storage medium stores computer instructions, and when the computer instructions are executed on a computing device, the computing device is enabled to execute the relevant method steps to implement the method executed by lock control module 1141 in the foregoing embodiment, refer to the descriptions of step 400a to step 402 in fig. 4, or the relevant descriptions of the first embodiment to the third embodiment, and are not described again here.

As a possible implementation manner, an embodiment of the present application further provides a computer program product, and when the computer program product runs on a computer, the computer executes the relevant steps to implement the method executed by lock control module 1141 in the above embodiment, see descriptions of step 400a to step 402 in fig. 4 or relevant descriptions of embodiments one to three, which are not described herein again.

As a possible implementation manner, an embodiment of the present application further provides an apparatus, which may specifically be a chip, a component, or a module, and the apparatus may include a processor and a memory connected to each other; when the device runs, the processor may execute the computer execution instruction stored in the memory, so that the chip executes the method performed by lock control module 1141 in each method embodiment, which is described in reference to steps 400a to 402 in fig. 4 or related descriptions of embodiments one to three, and for brevity, details are not described here again.

The lock management device, the computer storage medium, the computer program product, or the chip provided in the embodiment of the present application are all configured to execute the method corresponding to the lock control module 1141 provided above, and therefore, the beneficial effects achieved by the lock management device may refer to the beneficial effects in the corresponding method provided above, which are not described herein again.

As another possible implementation manner, the present application further provides a distributed system including a first computing device and a second computing device, where the second computing device is configured to send a lock access request to the first computing device; the lock access request is used for applying for executing access operation on a first lock, and the first lock is used for controlling the access authority of the first shared resource; the first lock is stored in a memory of a network card of the first computing device. The first computing device includes a lock management apparatus, which is used to perform the descriptions of the steps 400a to 402 in the method illustrated in fig. 4, or the descriptions related to the first embodiment to the third embodiment, and therefore, for brevity, no further description is given here.

Through the description of the foregoing embodiments, those skilled in the art will understand that, for convenience and simplicity of description, only the division of the functional modules is used for illustration, and in practical applications, the above function distribution may be completed by different functional modules as needed, that is, the internal structure of the device may be divided into different functional modules, so as to complete all or part of the functions described above.

The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions described in accordance with the embodiments of the application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device including one or more available media integrated servers, data centers, and the like. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

While the invention has been described with reference to specific embodiments, the scope of the invention is not limited thereto, and those skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the invention. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (15)

1. A lock management method, characterized in that the method comprises:

a network card of a first computing device acquires a lock access request, wherein the lock access request is used for applying for executing access operation on a first lock, and the first lock is used for controlling the access authority of a first shared resource; the first lock is stored in a first memory of the network card;

and the network card responds to the lock access request and triggers the access operation of the first lock.

2. The method of claim 1, wherein prior to the network card of the first computing device acquiring the lock access request, the method further comprises:

the network card determines a latch storage strategy according to the available storage space of the first memory;

the latch storage strategy comprises: a full offload policy and a partial offload policy, the full offload policy to complete a management operation of a full lock managed by a processor of the first computing device; the partial offload policy is to complete a management operation of a first set of locks managed by a processor of the first computing device, the first set of locks including at least one of a full set of locks managed by the processor.

3. The method of claim 2,

the full offload policy includes: when the available storage space of the first memory is larger than a first threshold value, all latches managed by a processor of the first computing device are stored in the first memory;

the partial unloading comprises: storing the first lock set in the first memory when available storage space of the first memory is not greater than a second threshold.

4. The method of any of claims 1-3, wherein the first lock is stored in a second memory of the first computing device; the method further comprises the following steps:

the network card migrates at least one lock in the second storage to the first storage, the at least one lock including the first lock.

5. The method of claim 4, wherein the network card migrating the one or more locks in the second memory to the first memory comprises:

and the network card determines a second lock set in the second memory according to the frequency of accessed locks, and migrates each lock in the second lock set to the first memory, wherein the first lock is any lock in the second lock set.

6. The method according to any one of claims 1 to 5, characterized in that the method further comprises:

the processor determines a third set of locks in the first memory based on a frequency with which the locks are accessed, and migrates each lock in the third set of locks to a second memory of the first computing device.

7. A lock management apparatus, provided in a first computing device, includes a communication module, a processing module, and a first storage module:

the acquiring module is configured to acquire a lock access request, where the lock access request is used to apply for performing an access operation on a first lock, and the first lock is used to control an access right of a first shared resource; the first lock is stored in the first storage module;

and the processing module is used for responding to the lock access request and triggering the access operation of the first lock.

8. The apparatus of claim 7, wherein the processing module is further configured to determine a latch storage policy according to an available storage space of the first storage module;

the latch storage strategy comprises: a full offload policy and a partial offload policy, the full offload policy to complete a management operation of a full lock managed by a processor of the first computing device; the partial offload policy is to complete a management operation of a first set of locks managed by a processor of the first computing device, the first set of locks including at least one of a full set of locks managed by the processor.

9. The apparatus of claim 8, wherein the full offload policy comprises: when the available storage space of the first storage module is larger than a first threshold value, all the latches managed by the processor of the first computing device are stored in the first storage module;

the partial unloading comprises: storing the first set of locks to the first storage module when the available storage space of the first storage module is not greater than a second threshold.

10. The apparatus of any of claims 7-9, wherein the first lock is stored in a second memory of the first computing device; the processing module is further configured to: migrating at least one lock in the second memory to the first memory, the at least one lock including the first lock.

11. The apparatus of claim 10,

the processing module is specifically configured to: determining a second lock set in the second storage module according to the frequency of accessed locks, and migrating each lock in the second lock set to the first storage module, wherein the first lock is any one lock in the second lock set.

12. The apparatus according to any one of claims 7 to 11,

the processor is specifically configured to: determining a third set of locks in the first storage module based on the frequency with which the locks are accessed, and migrating each lock in the third set of locks to a second storage module of the first computing device.

13. A network card comprising a processor and a memory, the memory for storing a lock, the processor for performing the method of any one of claims 1 to 6.

14. A computing device, wherein the computing device comprises a network card;

the network card for performing the method of any one of claims 1 to 6.

15. A distributed system, comprising a first computing device and a second computing device, the first computing device comprising a lock management apparatus;

the second computing device is used for sending a lock access request to the first computing device; the lock access request is used for applying for executing access operation on a first lock, and the first lock is used for controlling the access authority of the first shared resource; the first lock is stored in a memory of a network card of the first computing device;

the lock management apparatus of the first computing device, configured to perform the method of any of claims 1 to 6.

Images