WO2022001303A1

WO2022001303A1 - Lock management method, apparatus, and device

Info

Publication number: WO2022001303A1
Application number: PCT/CN2021/088656
Authority: WO
Inventors: 程宏才; 郭海涛; 张斌; 周罗青
Original assignee: 华为技术有限公司
Priority date: 2020-06-29
Filing date: 2021-04-21
Publication date: 2022-01-06
Also published as: CN113934516A

Abstract

A lock management method, apparatus, and device. The lock management method can comprise: a lock management module obtains a lock application request from a first CPU core, the lock application request being used to request to allocate a lock to a first program in the first CPU core; the lock management module allocates a lock to the first program in response to the lock application request; and the lock management module sends a first signal to an interrupt distribution module, the first signal being used to instruct the interrupt distribution module to stop distributing an interrupt to the first CPU core. In the described method, interrupt distribution to the first CPU core is stopped when the first program accesses a critical area, so that after the first program successfully applies for a lock, the first program cannot be interrupted by the interrupt, and maintains access to the critical area until execution in the critical area is completed, thereby reducing the time spent waiting for acquisition by another program, and reducing the consumption of CPU resources and memory resources.

Description

A lock management method, device and equipment

technical field

The present application relates to the field of computers, and in particular, to a lock management method, device and device.

Background technique

A multi-core central processing unit (CPU) runs multiple threads in parallel. A thread is a single sequential control flow in program execution, the smallest unit of program execution flow, and the basic unit of processor scheduling and dispatch. A process can have one or more threads, and each thread shares the program's memory space. In order to ensure the safe access of a program to a certain resource and maintain data consistency, programs running in parallel generally need to use a lock mechanism for synchronization, so as to ensure the consistency of shared resource data during program operation.

At present, after a thread acquires the lock, it can access the critical section and perform operations in the critical section. After the execution of the critical section is completed, the thread releases the lock. At this time, other threads can obtain the lock to execute their own critical section. Since at most one thread can acquire the lock at the same time, the critical section can only be executed by at most one thread at a certain time. In this way, the method of locking ensures that the critical section will not be parallelized. However, after a thread acquires the lock, other threads need to wait for the lock to be released, and other threads will keep trying to acquire the lock while waiting for the lock to be released, occupying CPU resources. It can be seen that the longer the thread that obtains the lock executes in the critical section, the longer the waiting time of other threads will be, which will cause unnecessary consumption of CPU resources for a long time.

SUMMARY OF THE INVENTION

The present application provides a lock management method, device and device to improve performance and save resources.

In the first aspect, the present application provides a lock management method, which can be applied to a lock management module, which can be arranged in a first CPU and communicate with at least one CPU core and an interrupt distribution module in the first CPU. , the at least one CPU core includes the first CPU core.

In the present application, the above lock management method may include: the lock management module obtains a lock application request from the first CPU core to request to allocate a lock for the first program in the first CPU core; the lock management module responds to the lock application request, for The first program distributes the lock; the lock management module sends a first signal to the interrupt distribution module to instruct the interrupt distribution module to stop distributing the interrupt to the first CPU core.

It can be understood that the step of the lock management module assigning the lock to the first program and the step of the lock management module sending the first signal to the interrupt distribution module can be performed in parallel, that is, the lock management module can respond to the lock application request and assign the lock to the first program. At the same time, the first signal is sent to the interrupt distribution module. Of course, the above two steps can also be performed in series, that is, the lock management module first allocates the lock to the first program, and then sends the first signal to the interrupt distribution module.

In this application, when the first program accesses the critical area, it stops distributing the interrupt to the first CPU core, so that the first program can keep accessing the critical area without interruption after applying for the lock until the completion of the lock. Execution of critical sections. Since the interrupt is stopped to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program execution after the interruption ends is avoided. Further, after the first program finishes executing the critical section, the lock management device releases the lock so that other programs can try to acquire the lock, thus reducing the time for other programs to wait for acquisition, and reducing the consumption of CPU resources and memory resources.

In a possible implementation manner, the lock management module may first receive a lock application request sent by at least one CPU core in the first CPU to request to allocate locks for the programs in each CPU core, and then the lock management module may request a lock from the program in each CPU core. The first CPU core is determined from at least one CPU core, and then a lock application request from the first CPU core is obtained.

It can be understood that the lock management module can determine the first CPU core from at least one CPU core according to a preset rule. Optionally, the preset rules may include: the CPU core corresponding to the program with the highest priority in at least one CPU core; or, the CPU core that first sends the lock application request to the lock management module in the at least one CPU core ; or, a CPU core corresponding to a group of programs with the highest group priority in at least one CPU core; or, a core corresponding to a program located at the head of the queue in a group of programs. Of course, the preset rule may also be other, which is not specifically limited in this embodiment of the present application.

In this application, after the lock management module can obtain the lock application request sent by at least one CPU core, it needs to perform arbitration to confirm which CPU core to assign the lock to, so as to ensure that the critical area is uniquely accessed and execute the critical area. operation.

In another possible implementation manner, the first program is used to maintain access to the critical section after acquiring the lock until the operation on the critical section is completed, and the critical section is used to indicate a program segment that accesses a shared resource. In this way, after the first program acquires the lock, it keeps accessing the critical section without interruption until the execution of the critical section is completed, and then the execution of the critical section is completed as soon as possible.

In another possible implementation manner, after allocating the lock to the first program, the lock management module may also release the lock corresponding to the first program, and send a second signal to the interrupt distribution module to instruct the interrupt distribution module to restore the lock to the first program. A CPU core dispatches interrupts.

It can be understood that the step of the lock management module releasing the lock for the first program and the step of the lock management module sending the second signal to the interrupt distribution module can be performed in parallel, that is, the lock management module can respond to the lock application request and release the lock for the first program. At the same time, the second signal is sent to the interrupt distribution module. Of course, the above two steps can also be performed in series, that is, the lock management module first releases the lock for the first program, and then sends the second signal to the interrupt distribution module.

In the present application, after the first program completes the execution of the critical section, the lock management module releases the lock corresponding to the first program, so that other programs can try to acquire the lock. In this way, the time for other programs to wait for acquisition is reduced, and the CPU resources are reduced. and the consumption of memory resources; further, since the interrupt distribution to the first CPU core is resumed when the first program completes the operation of executing the critical section, the performance of the CPU is guaranteed.

In another possible implementation manner, after the lock management module allocates the lock to the first program, if the first program completes the access to the critical section, it can send a lock release request to the lock management module. In this way, the lock management module will The lock release request from the first CPU core can be obtained, and then, the lock management module responds to the lock release request and releases the lock corresponding to the first program; the lock management module can also respond to the lock release request and send a second signal to the interrupt distribution module , to instruct the interrupt distribution module to resume distributing the interrupt to the first CPU core.

It can be understood that after the first program completes the access to the critical area, it can actively request to release the lock, and the lock management module instructs the interrupt distribution module to resume the distribution of the interrupt to the first CPU core, so that other programs can try to acquire the lock as soon as possible, This reduces the time for other programs to wait for acquisition, and reduces the consumption of CPU resources and memory resources.

In another possible implementation manner, when the lock management module allocates the lock to the first program, it can also start a timer module, that is, the lock management module can set a period of time by itself for the first program to access the critical area , when the timer times out, regardless of whether the first program completes the access to the critical section, the lock management module will send a second signal to the interrupt distribution module to indicate that the interrupt distribution to the first CPU core will be resumed.

It can be understood that after the lock management module sends the second signal to the interrupt distribution module, if the first program has not completed the access to the critical area, the first program can also continue to access the critical area; if the first program has completed the access to the critical area; access to the area, the first program may send a lock release request to the lock management module to request to release the lock.

In the present application, the lock management module sets a period of time by itself. During this period of time, the first program accesses the critical area. At the end of this period of time, regardless of whether the first program completes the access to the critical area, the managed module will The request resumes distributing the interrupt to the first CPU core to guarantee the performance of the CPU.

In another possible implementation manner, the first program is a user mode program.

In another possible implementation manner, the first CPU includes at least one CPU core, a lock management module, and an interrupt distribution module, at least one CPU core, a lock management module, and an interrupt distribution module communicate, and the at least one CPU core includes the first CPU core . It can be understood that the lock management module can be implemented by a hardware module.

In a second aspect, the present application provides a lock management device. The lock management device may be a chip or a system-on-chip in a processor, or may be a processor for implementing the first aspect or any possible implementation of the first aspect. The functional modules of the method described in the manner. For example, the lock management device includes: a first communication unit, an allocation unit, and a second communication unit; wherein, the first communication unit is used to obtain a lock application request from the first CPU core, and the lock application request is used to request The first program in the first CPU core distributes the lock; the distribution unit is used to respond to the lock application request and distribute the lock to the first program; the second communication unit is used to send the first signal to the interrupt distribution device, and the first signal is used for The interrupt distribution module is instructed to stop distributing interrupts to the first CPU core.

In the present application, when the first program accesses the critical area, the lock management device stops distributing interrupts to the first CPU core, so that the first program can maintain access to the critical area without being interrupted by the interrupt after applying for the lock. until the execution of the critical section is completed. Since the interrupt is stopped to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program execution after the interruption ends is avoided. Further, after the first program finishes executing the critical section, the lock management device releases the lock so that other programs can try to acquire the lock, thus reducing the time for other programs to wait for acquisition, and reducing the consumption of CPU resources and memory resources. .

In a possible implementation manner, the above-mentioned apparatus further includes: a determining unit; then, the first communication unit is further configured to obtain a lock application request from at least one CPU core before obtaining a lock application request from the first CPU core , a lock application request from at least one CPU core is used for requesting to allocate locks for programs in at least one CPU core, and at least one CPU core includes a first CPU core; a determination unit is used to determine the first CPU core from at least one CPU core .

In another possible implementation manner, the above determining unit is specifically configured to determine the first CPU core from at least one CPU core according to a preset rule.

In another possible implementation manner, the first program is used to maintain access to the critical section after acquiring the lock until the operation on the critical section is completed, and the critical section is used to indicate a program segment that accesses a shared resource.

In another possible implementation manner, the above-mentioned device further includes: a release unit, configured to release the lock corresponding to the first program after the distribution unit allocates the lock to the first program; the second communication unit is further configured to send the interrupt to the The distribution device sends a second signal, where the second signal is used to instruct the interrupt distribution device to resume distribution of the interrupt to the first CPU core.

In another possible implementation manner, the first communication unit is further configured to obtain a lock release request from the first CPU core before the release unit releases the lock corresponding to the first program, and the lock release request is used to request to release the first program The lock corresponding to the program; the second communication unit is used for sending a second signal to the interrupt distribution device in response to the lock release request.

In another possible implementation manner, the above-mentioned apparatus further includes: a timing unit for triggering the timer module when the allocation unit allocates the lock to the first program; and a second communication unit for triggering the timer module when the timer module times out. A second signal is sent to the interrupt distribution device.

In a third aspect, the present application provides a processor, comprising: at least one CPU core, a bus, a lock management device, and an interrupt distribution device, wherein at least one CPU core, a lock management device, and an interrupt distribution device communicate through a bus, and at least one CPU The core includes a first CPU core; and a lock management apparatus configured to execute the lock management method described in the first party or any possible implementation manner of the first aspect.

In a possible implementation manner, the interrupt distribution device is configured to receive the first signal sent by the lock management device; in response to the first signal, stop distribution of the interrupt to the first CPU core.

In another possible implementation manner, the interrupt distribution device is further configured to receive a second signal sent by the lock management device; in response to the second signal, resume distribution of the interrupt to the first CPU core.

In a fourth aspect, the present application provides an electronic device, including: a processor, where the processor is configured to execute the lock management method described in the first party or any possible implementation manner of the first aspect.

In this application, the electronic device may be a computing device, a storage device, a network device, or the like.

In a fifth aspect, the present application provides a lock management device, comprising: a processor, a memory, a first interface and a second interface, the processor is respectively coupled to the memory, the first interface and the second interface, and the processor communicates with the first interface through the first interface. At least one CPU core communicates with the interrupt distribution device through the second interface, and the processor is configured to read and execute the instructions in the memory, so as to implement the above-mentioned first party or any possible implementation manner of the first aspect. Lock management method.

In a sixth aspect, the present application provides a computer-readable storage medium, where the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, are used to execute the first aspect or any possible implementation of the first aspect. The lock management method described in the method.

In a seventh aspect, the present application provides a computer program or computer program product that, when the computer program or computer program product is executed on a computer, enables the computer to implement the first aspect or any possible implementation manner of the first aspect. The lock management method described above.

It should be understood that the second to seventh aspects of the present application are consistent with the technical solutions of the first aspect of the present application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation manner are similar, and will not be repeated.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present application more clearly, the accompanying drawings required in the embodiments of the present application will be described below.

FIG. 1 is a schematic diagram of a use access mode of a lock in an embodiment of the application;

2 is a schematic time sequence diagram of an operation of a thread A executing a critical section in an embodiment of the present application;

3 is a schematic structural diagram of a processor in an embodiment of the present application;

4 is a schematic structural diagram of a lock management device and an interrupt distribution device in an embodiment of the application;

5 is a schematic flowchart of a lock management method in an embodiment of the present application;

6 is a schematic diagram of a logical structure of a hardware queue in an embodiment of the present application;

7 is a schematic structural diagram of a lock management device in an embodiment of the application;

FIG. 8 is a schematic structural diagram of an electronic device in an embodiment of the present application.

detailed description

The embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

FIG. 1 is a schematic diagram of an access method of a lock in an embodiment of the present application. Referring to FIG. 1 , after acquiring the lock, thread A will perform the operation of its own critical section, and release it after the execution of its critical section is completed. Then, other threads, such as B thread or C thread, can acquire the lock and execute their own critical section code after acquiring the lock. However, since only one thread can acquire the lock at most, the critical section can only be executed by at most one thread at a certain time. In this way, the critical section is protected from being parallelized by locking.

It should be noted that, in this embodiment of the present application, a critical section refers to a program segment that accesses shared resources, and these shared resources cannot be accessed by multiple programs at the same time. When a program executes operations in a critical section, other programs must wait to ensure that these shared resources are used by mutual exclusion.

In the development and operation of multi-program software, the locks that can be obtained by programs are used to control resource access, which can include spin locks, mutex locks, and improved mutex locks. Of course, the above locks may also be other locks derived from spin locks and/or mutual exclusion locks, which are not specifically limited in this embodiment of the present application.

It should be noted that the "program" mentioned in the embodiments of the present application may be understood as processes or threads running in the CPU core, which are not specifically limited in the embodiments of the present application.

The working mechanism of the above lock is described below by taking the thread applying for or releasing the spin lock as an example.

Spin lock is a kind of lock used for fast synchronization between multiple threads. It is widely used when multiple threads need fast mutual exclusion access, especially when the critical section is short, the use of spin lock can effectively reduce the lock itself. The impact of overhead on application performance.

For example, the logic of a typical spinlock acquisition function can look like this:

spin_lock_get{}{

while (failure to read and write public variables);

}

Among them, the above public variables are equivalent to flags. The operation of reading and writing public variables is generally to set or check the value of the public variable; if the value of the variable is set, it means that the lock is occupied, and clearing the value of the variable means that the lock is free and can be used by used by other threads. If the thread tries to acquire the lock and fails, it will continue to try to acquire the lock in a loop until the lock is successfully acquired. That is to say, when a thread fails to acquire a spin lock, the thread will keep trying to acquire the spin lock next time instead of releasing CPU resources to do other work. The advantage of this is that after other threads release the spin lock, since the current thread is always in the execution state, the current thread can quickly acquire the released lock without going through more complex thread scheduling and other processes; and At the same time, the disadvantage of doing this is also obvious, that is, in the process of the current thread waiting to acquire the lock, the CPU resources will be occupied all the time, and the tasks of other threads cannot be executed, which is an unnecessary waste of CPU resources, especially in the Under the condition of long waiting time, there will be a greater waste.

Further, since the operation of the program to acquire the spin lock is realized by reading and writing memory public variables, when the program waits to acquire the spin lock, it will not only occupy CPU resources, but also occupy unnecessary memory bandwidth resources. . In order to reduce the consumption of CPU resources and memory resources by the waiting thread, the thread holding the spin lock needs to complete the operation of the critical section as soon as possible to release the spin lock. However, the execution time of a thread's critical section depends not only on the logical complexity of the critical section, but also affected by the preemptive execution of other codes. For example, FIG. 2 is a schematic time sequence diagram of the operation of thread A executing a critical section in an embodiment of the present application. Referring to FIG. 2 , during the execution of thread A in the critical section, CPU resources are preempted by a program with a higher priority, and the CPU If the core responds to the interrupt first, then the execution of the critical section of thread A must wait until the execution of the interrupt processing is completed before continuing. The time for thread A to release the lock will be delayed accordingly, and the waiting time of other threads, such as thread B and thread C Prolonged, resulting in unnecessary waste of the existence of CPU resources, especially under the condition of a long waiting time, there will be a greater waste.

In addition, according to the different permission states in which the program is expected to run, programs can generally be divided into user-mode programs and kernel-mode programs. User-mode programs refer to programs that run under the lowest permission of the CPU, while kernel-mode programs can be narrowly defined as A program that needs to run under the highest authority of the CPU can also generally refer to a program that runs under a higher authority than the user mode authority. With reference to the embodiment of the present application, the instruction to access the memory variable is a low-privilege instruction, then the user-mode program (user-mode thread or user-mode process) can be directly executed, but operations such as prohibiting interruption and prohibiting preemption are all high-privilege operations. , the user mode program cannot be executed directly, but needs to be executed by the system call kernel mode program, but the system call is a very time-consuming operation, which usually takes hundreds of nanoseconds or even microseconds to complete. During the process, preemption by other programs will occur, thus affecting the execution time of the program to the critical section.

Further, if the program is interrupted by an interrupt when the operation of the critical section is executed, there may also be a problem that the CPU core selects a higher priority program to execute instead of the original program after the interrupt ends, resulting in a deadlock problem.

Then, in order to solve the above problem, an embodiment of the present application provides a processor, such as a CPU, and the processor can be set in a device such as a computing device, a storage device, and a network device. FIG. 3 is a schematic diagram of a hardware structure of a processor in an embodiment of the present application. Referring to the solid line in FIG. 3 , the processor 100 may include: at least one processor core (core) 101, a bus 102, a lock management device 103, The interrupt distribution device 104 , wherein the processor core 101 includes a CPU core, and each of the processor core 101 , the lock management device 103 , and the interrupt distribution device 104 communicates through the bus 102 .

In some possible implementations, referring to the dotted line in FIG. 3 , the lock management apparatus 103 and the interrupt distribution apparatus 104 may also communicate directly.

In the embodiment of the present application, the above-mentioned bus may be a ring bus, which is used as an interconnection bus between various cores in the CPU and between other hardware modules. Here, other hardware modules may include a lock management device, an interrupt distribution A device, a memory controller, a PCIe root complex, etc., are not specifically limited in the embodiments of the present application.

The above-mentioned lock management device is used to obtain a lock application request from the first CPU core; in response to the lock application request, a lock is allocated for the first program in the first CPU core, and a first signal is sent to the interrupt distribution device to indicate the interrupt distribution The device stops dispatching interrupts to the first CPU core.

In other embodiments of the present application, the lock management device is further configured to release the lock corresponding to the first program, and send a second signal to the interrupt distribution device to instruct the interrupt distribution device to resume distributing the interrupt to the first CPU core.

The above-mentioned interrupt distribution device is configured to receive the first signal sent by the lock management device; in response to the first signal, stop distribution of interrupts to the first CPU core.

In other embodiments of the present application, the interrupt distribution device is further configured to receive a second signal sent by the lock management device; and in response to the second signal, resume distribution of the interrupt to the first CPU core.

Then, from the perspective of the first CPU core, the first CPU core applies for a lock to the lock management device, the lock management device allocates a lock to the first CPU core, and notifies the interrupt distribution device to stop distributing interrupts to the first CPU core; When a CPU core releases the lock, the lock management device notifies the interrupt distribution device to resume distribution of the interrupt to the first CPU core.

In practical applications, the above lock management apparatus may be implemented based on a hardware queue, a ring, an identification bit stored in a register, or other logic. The lock management device can be realized by using programmable devices, such as application specific integrated circuit (ASIC), register transfer level (RTL), field programmable gate array (FPGA), etc. Of course, depending on the type of the CPU, other programmable devices may also be used for implementation, or the lock management apparatus may also be implemented with a logic circuit, which is not specifically limited in this embodiment of the present application. The above-mentioned interrupt distribution device can be realized based on the structure of the interrupt controller of the CPU, and the interrupt distribution device can realize the above-mentioned functions by using a hardware structure, or can realize the above-mentioned functions by software, for example, use any one of the processor cores in the processor 100 to realize the above-mentioned functions. .

In the embodiment of the present application, FIG. 4 is a schematic structural diagram of the lock management device and the interrupt distribution device in the embodiment of the present application. Referring to the solid line in FIG. 4 , the lock management device 103 may include: a lock management module 401, a first An interface module 402 and a second interface module 403 . Wherein, the first interface module is used to communicate with the CPU core, and the second interface module is used to communicate with the interrupt distribution device. In practical applications, each module in the lock management device may be implemented by hardware modules such as independent programmable devices and logic circuits.

Still referring to FIG. 4 , the above-mentioned interrupt distribution device 104 may include: an interrupt distribution module 411, a third interface module 412 and a fourth interface module 413; a third interface module for communicating with the lock management device, a fourth interface module Used to communicate with at least one CPU core for interrupt dispatch. Wherein, the third interface module and the second interface module can communicate through a bus, or can communicate directly.

The above-mentioned first interface module, second interface module, third interface module and/or fourth interface module can be implemented by using, for example, a transceiver circuit, an optical transceiver, and the like.

It should be noted that, in this embodiment of the present application, the lock allocated by the lock management device to the first program in the first CPU may be a spin lock or an improved mutual exclusion lock. Locks derived from spinlocks and/or mutex locks, which are not specifically limited.

The above-mentioned first program may be a user-mode program, and the first program may also be understood as a user-mode thread or a user-mode process.

The interrupts that the interrupt distribution module stops or resumes distribution to the first CPU core are maskable interrupts, and the maskable interrupts are generated by peripheral devices with interrupt capability. That is to say, after the first program acquires the lock, it notifies the interrupt distribution apparatus to stop or resume the distribution of maskable interrupts for the first CPU core.

Taking the lock as a spin lock as an example, the following describes a lock management method provided by an embodiment of the present application in combination with the structure of the above-mentioned CPU.

FIG. 5 is a schematic flowchart of a lock management method in an embodiment of the present application. Referring to the solid line in FIG. 6 , the method may include:

S501: The first CPU core sends a lock application request to the lock management module;

When the first program running in the first CPU core needs to access the critical area, the first CPU core sends a lock application request to the lock management module through the first interface module, so as to request the lock management module to allocate a lock to the first program, so that the first Programs can access critical sections and perform operations in critical sections.

In some possible implementations, at the same time as the first CPU core lock application request, other cores of the CPU can also send a lock application request to the lock management module through the first interface module, that is, the first interface module can be at least A CPU core accesses at the same time and receives a lock application request from at least one CPU core.

S502: The lock management module allocates a lock to the first program in response to the lock application request.

When only the first CPU core sends a lock application request to the lock management module, the lock management module responds to the lock application request and allocates the lock to the first program.

In practical applications, in addition to the first program in the first CPU core requesting access to the critical section, other threads may also send lock application requests to the lock management module at the same time. Then, the lock management module obtains the After a lock request is made, arbitration is required to confirm which CPU core the lock is assigned to. Suppose, the lock management module arbitrates the decision to assign the lock to the first program. Then, the lock management module can only respond to the lock application request sent by the first CPU core and assign the lock to the first program. In this way, the first program can be unique Access the critical section and perform the operation of the critical section.

S503: The lock management module sends a first signal to the interrupt distribution module;

The first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.

While executing S502 or after executing S502, the lock management module communicates with the third interface module through the second interface module, sends a first signal to the interrupt distribution module, and notifies the interrupt distribution module to stop distributing interrupts to the first CPU core, so that the first signal is sent to the interrupt distribution module. A program can maintain access to the critical section without being disturbed by interruptions, complete the operation on the critical section as soon as possible, reduce the time that other threads wait to acquire the lock, and reduce the consumption of CPU resources and memory resources.

S504: The interrupt distribution module stops distributing interrupts to the first CPU core in response to the first signal;

In some possible implementations, S502 and S503 may be executed sequentially during the execution process, for example, S502 is executed first, then S503 is executed, or, S503 is executed first, and then S502 is executed; of course, S502 and S503 can also be executed at the same time. The execution sequence of S502 and S503 is not specifically limited in this embodiment of the present application.

At this point, the lock application process is completed.

In some possible implementations, after the first program completes the execution of the critical section, it needs to release the lock so that other programs can acquire the lock as soon as possible. Then, as shown by the dotted line in FIG. 6 , after S504, the above lock Management methods can also include:

S505: the lock management module releases the lock corresponding to the first program;

S506: The lock management module sends a second signal to the interrupt distribution module;

The second signal is used to instruct the interrupt distribution module to resume distributing the interrupt to the first CPU core.

In some possible implementations, S505 and S506 may be executed sequentially in the execution process, for example, S505 is executed first, then S506 is executed, or, S506 is executed first, and then S505 is executed; of course, S505 and S506 can also be executed at the same time. The execution sequence of S505 and S506 is not specifically limited in this embodiment of the present application.

S507: The interrupt distribution module resumes distributing the interrupt to the first CPU core in response to the second signal.

When releasing the lock or after releasing the lock, the lock management module may send a second signal to the interrupt distribution module through the communication between the second interface module and the third interface module to instruct the interrupt distribution module to resume distributing the interrupt to the first CPU core. The interrupt distribution module resumes distributing the interrupt to the first CPU in response to the second signal. Then, when the first CPU core receives the interrupt distributed by the interrupt distribution module, it can respond to the interrupt and process the interrupt.

In some possible embodiments, after the above-mentioned first program completes the execution of the critical section, it may request the lock management module to release the lock allocated to the first program. Then, S505 may include: the lock management module obtains the lock from the first CPU core. In response to the lock release request, the lock management module releases the lock corresponding to the first program in response to the lock release request.

After the first program completes the execution of the critical section, the first CPU core may send a lock release request to the lock management module through the first interface module, so as to request the first CPU core to release the lock application process described in S501 to S504 as follows For the lock allocated by the first program, the lock management module releases the lock in response to the lock release request sent by the first CPU core. At this time, other programs can try to acquire the lock. In this way, the first program immediately instructs the lock management module to release the lock after completing the operation in the critical section, so that other programs can acquire the lock as soon as possible, reduce the waiting time of other programs, and reduce the consumption of CPU resources and memory resources.

Correspondingly, before, after or at the same time as executing S505, the lock management module sends a second signal to the interrupt distribution module in response to the lock release request to instruct the interrupt distribution module to resume distributing the interrupt to the first CPU core.

In some possible embodiments, in addition to instructing the interrupt distribution module to resume distributing the interrupt to the first CPU core according to the request of the first CPU core, the lock management module may also instruct the interrupt distribution module to resume distributing the interrupt to the first CPU core by itself. Then, referring to the dotted line in FIG. 4 , the above lock management device 103 may further include: a timer module 404; here, the duration of the timer module 404 can be understood as the duration for which the first program is expected to perform the operation of the critical section. The specific value of can be set according to the performance of the CPU, the requirements of the operating system, etc., which is not specifically limited in this embodiment of the present application.

In practical applications, the timer module can be, but is not limited to, implemented by a timer circuit or a timer program, which is not specifically limited in this embodiment of the present application.

Then, after the lock management module allocates the lock to the first program through S502, the timer module is started, and the timer module starts timing. When the timer module times out, the lock management module sends a second signal to the interrupt distribution module, and the interrupt distribution module responds to the second signal and resumes distributing the interrupt to the first CPU. Then, when the first CPU core receives the interrupt distributed by the interrupt distribution module After that, you can respond to the interrupt and process the interrupt.

In some possible implementations, the lock management module may release the lock allocated to the first program before or after the timer module times out, which is not limited in this embodiment of the present application.

At this point, the lock release process is completed.

In some possible implementations, in the process of allocating the lock to the first program through S502, the lock management module may record which CPU core program is allocated the lock for, such as the first CPU core, in this way, the lock management module is executing At S503, the interrupt distribution module may be instructed to stop distributing interrupts to the recorded CPU core, that is, the first CPU core.

Correspondingly, in the process of releasing the lock for the first program through S505, the lock management module can record which CPU core program has released the lock, such as the first CPU core, so that when the lock management module executes S506, it can indicate The interrupt distribution module resumes distributing the interrupt to the recorded CPU core, that is, the first CPU core.

Through the above lock application process and lock release process, the first program in the user mode can keep accessing the critical area without interruption after applying for the lock until the execution of the critical area is completed. Since the interrupt is stopped to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program execution after the interruption ends is avoided. Further, after the first program finishes executing the critical section, the lock management device releases the lock so that other programs can try to acquire the lock, thus reducing the time for other programs to wait for acquisition, and reducing the consumption of CPU resources and memory resources. Further, since the interrupt is stopped to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program execution after the interruption ends is avoided.

In some possible embodiments, the execution process of the above S501 to S507 will be described by taking the lock management apparatus as an example of hardware queue logic implementation.

6 is a schematic diagram of the logical structure of a hardware queue in an embodiment of the present application. Referring to FIG. 6 , the read-write interface of the hardware queue allows multiple CPU cores to access simultaneously, and the read-write interface arbitrates to determine the reading of the contents of the queue by multiple CPUs. Write access sequence, so as to realize serial writing when finally reading and writing data to the queue storage area (it is understandable that all reading processes are serial, all writing processes are serial, and there can be writing processes at the same time as reading). When a CPU core writes a data to the queue, there will be one more data in the queue storage, and the newly added data is located at the end of the valid data in the queue storage area; when a CPU core requests to read a data from the queue, One piece of data is also reduced in the queue storage, and the reduced data is the data previously located at the head of the valid data in the storage area. The data in the queue storage area will always keep the relative order according to the order in which it was written. When the queue is reduced by one data due to reading, the subsequent data will automatically move forward one position to ensure that the queue can read the data next time. . If the storage area in the queue has all stored valid data, that is, it is in a full state, the subsequent write operation of the CPU core will get a full feedback message and need to wait for rewriting; if there is no valid data in the queue storage area, it is in a full state. In the empty state, subsequent read operations of the CPU core will get an empty feedback message and need to wait for re-reading.

When the hardware queue is initialized, a valid data is stored in the queue. First, at least one CPU core in the CPU accesses the read interface at the same time, sends a lock application request (here, the lock application request can be understood as a read signal), and the read interface arbitrates to determine which program in the CPU core to assign the lock to. For example, the read interface can sort the programs in the CPU core by priority, and decide to allocate a lock to the first program with the highest priority. Accordingly, the read interface responds to the lock request request of the first CPU core, and the first program reads the queue The valid data in the header; alternatively, the read interface can sort the lock request requests sent by the CPU core in chronological order, and decide to allocate a lock to the first program that first sends a lock request request to the read interface. Accordingly, the read interface responds to the first program. The lock application request of the CPU core; the first program reads the valid data at the head of the queue. Of course, the read interface can also use other arbitration rules to decide which CPU core program to allocate locks to. For example, the read interface can also decide to allocate locks to a group of programs with the highest group priority, or to a group of programs that are at the head of the queue. The first program assigns a lock, etc., which are not specifically limited in this embodiment of the present application. Then, while allocating the lock to the first program, the read interface may send a first signal to the interrupt distribution device to instruct the interrupt distribution device to stop distributing interrupts to the first CPU core.

When the first program completes the execution of the critical section, it sends a lock release request to the write interface in the hardware queue (here, the lock release request can be understood as a write signal), and the write interface responds to the lock release request and writes valid data to the tail of the queue , complete the release of the lock. At the same time, the write interface may also send a second signal to the interrupt distribution apparatus to instruct the interrupt distribution apparatus to resume distributing the interrupt to the first CPU core.

Further, after the write interface writes valid data to the tail of the queue, the valid data will be automatically moved to the head of the queue so that other programs can read it later, and the relative order in the moved queue remains unchanged.

In practical applications, the read interface and the write interface can be physically separate or combined, and the function module in the read interface and the write interface that communicates with the CPU core can correspond to the first interface module, and the function module communicates with the interrupt distribution device. It may correspond to the above-mentioned second interface module, and the function module in the read interface that performs arbitration decision may correspond to the above-mentioned lock management module.

Alternatively, the execution process of the above S501 to S507 will be described by taking as an example that the lock management device is implemented based on the register identification bit logic.

An identification bit is set in the register to indicate the state of the lock. If the identification position is 1, it means that the lock is not allocated and can be acquired. On the contrary, if the identification position is 0, it indicates that the lock has been allocated and cannot be acquired. First, when the register is initialized, the flag bit is set to 1. First, at least one CPU core in the CPU accesses the registers at the same time, sends a lock application request, and the register arbitration decides the program in which CPU core to assign the lock to. For example, the register can sort the programs in the CPU core according to the priority, and decide to allocate the lock to the first program with the highest priority. Accordingly, the register responds to the lock application request of the first CPU core, sets the flag to 0, and informs the first program of the first CPU core. A CPU core, or a register can sort the lock request requests sent by the CPU core in chronological order, and decide to allocate a lock to the first program that first sends a lock request request to the register. Accordingly, the read interface responds to the lock request of the first CPU core Apply for a request, set the flag to 0, and inform the first CPU core. Of course, the register can also use other arbitration rules to decide which program in the CPU core to allocate the lock to. For example, the register can also decide to allocate the lock to the group of programs with the highest group priority, or to the first group of programs at the head of the queue. A program allocates locks, etc., which are not specifically limited in this embodiment of the present application. Then, while allocating the lock to the first program, the register may send a first signal to the interrupt distribution apparatus to instruct the interrupt distribution apparatus to stop distributing interrupts to the first CPU core.

When the first program completes the execution of the critical section, it sends a lock release request to the register, and the register responds to the lock release request and sets the flag to 1 to complete the lock release. At the same time, the write interface may also send a second signal to the interrupt distribution apparatus to instruct the interrupt distribution apparatus to resume distributing the interrupt to the first CPU core.

It can be seen from the above that other programs access the register. If the flag bit is read as 0, it indicates that the lock has been allocated, and other programs wait and continue to try to acquire the lock; and if the flag bit is read as 1, it indicates that the lock has not been obtained. allocation, the program can acquire the lock.

Of course, the lock management device may also be in other implementation forms, which are not specifically limited in the embodiments of the present application.

In some possible implementation manners, the above-mentioned first program may also be a kernel-mode program, and the first program may also be understood as a kernel-mode thread or a kernel-mode process. Because the kernel mode program can perform operations such as prohibiting interrupts, prohibiting preemption, etc., but the kernel mode program realizes prohibiting interrupts or prohibiting preemption by not responding to interrupts, which will cause the interrupts to be delayed and not be responded to, increasing the consumption of interrupt response. , then, for the first program in the kernel state, the methods described in S501 to S505 can be executed, so that the interrupt distribution device can distribute interrupts with higher priority to other CPU cores after stopping distribution of interrupts to the first CPU core. CPU core to process, so that the interrupt can be responded to in time, improve real-time performance.

In some possible implementations, in order to meet application scenarios with high real-time requirements, such as in-vehicle systems or real-time operating systems, the lock management device may also allocate locks to multiple programs, and notify the interrupt distribution device to stop distributing corresponding interrupts. Specifically, the lock management device receives a lock application request sent by at least one CPU core, and allocates locks to multiple programs with high real-time requirements in one or more CPU cores, so as to ensure that these programs are executed as soon as possible and improve real-time performance.

Based on the same inventive concept, an embodiment of the present application further provides a lock management device. The lock management device may be a chip or a system-on-chip in a processor, or may be used in the processor to implement any of the possible implementations in the foregoing embodiments. The functional modules of the method described in the embodiment. For example, FIG. 7 is a schematic structural diagram 1 of a lock management apparatus in an embodiment of the present application. Referring to FIG. 7 , the lock management apparatus 700 may include: a first communication unit 701 , an allocation unit 702 and a second communication unit 703 ; Wherein, the first communication unit 701 is used to obtain a lock application request from the first CPU core, and the lock application request is used to request to allocate a lock for the first program in the first CPU core; the allocation unit 702 is used to respond to the lock application request, assign a lock to the first program; the second communication unit 703 is configured to send a first signal to the interrupt distribution apparatus, where the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.

In the embodiment of the present application, when the first program accesses the critical area, the lock management device stops distributing the interrupt to the first CPU core, so that the first program can not be interrupted by the interrupt after applying for the lock, and the access critical area is maintained. section until the execution of the critical section is complete. Since the interrupt is stopped to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program execution after the interruption ends is avoided. Further, after the first program completes the execution of the critical section as soon as possible, the lock management module releases the lock, so that other programs can try to acquire the lock, reduce the time for other programs to wait for acquisition, and reduce the consumption of CPU resources and memory resources.

It should be understood that the apparatus 700 in the embodiment of the present application may be implemented by an application specific integrated circuit (ASIC), or a programmable logic device (programmable logic device, PLD), and the above-mentioned PLD may be a complex programmable logical device (complex programmable logical device, CPLD), Field Programmable Gate Array (FPGA), Generic Array Logic (GAL) or any combination thereof. When the methods shown in FIGS. 1 to 7 can also be implemented by software, the apparatus 700 and its respective modules can also be software modules.

In some possible implementations, the above-mentioned apparatus further includes: a determining unit; then, the first communication unit is further configured to obtain a lock application request from at least one CPU core before obtaining a lock application request from the first CPU core, The lock application request from at least one CPU core is used for requesting to allocate a lock to a program in at least one CPU core, and the at least one CPU core includes the first CPU core; the determining unit is used for determining the first CPU core from the at least one CPU core.

In some possible implementations, the above determining unit is specifically configured to determine the first CPU core from at least one CPU core according to a preset rule.

In some possible implementations, the first program is used to maintain access to the critical section after acquiring the lock until the operation on the critical section is completed, and the critical section is used to indicate a program segment that accesses the shared resource.

In some possible implementation manners, the above-mentioned apparatus further includes: a release unit, configured to release the lock corresponding to the first program after the distribution unit allocates the lock to the first program; the second communication unit is further configured to send a message to the interrupt distribution apparatus. The second signal is used to instruct the interrupt distribution apparatus to resume distribution of the interrupt to the first CPU core.

In some possible implementations, the first communication unit is further configured to obtain a lock release request from the first CPU core before the release unit releases the lock corresponding to the first program, and the lock release request is used to request to release the lock corresponding to the first program The second communication unit is configured to send a second signal to the interrupt distribution device in response to the lock release request.

In some possible implementation manners, the above-mentioned apparatus further includes: a timing unit for triggering a timer module when the allocation unit allocates a lock to the first program; a second communication unit for triggering an interrupt when the timer module times out The distribution device transmits the second signal.

In some possible implementations, the first program is a user mode program.

The above-mentioned first communication unit may correspond to the first interface module in FIG. 4, and the second communication unit may correspond to the second interface module in FIG. 4; the allocation unit, the determination unit, the release unit and the timing unit may be one or more processor.

Based on the same inventive concept, an embodiment of the present application further provides an electronic device, including: a processor, where the processor is configured to execute the lock management method described in any possible implementation manner of the foregoing embodiments.

In the embodiment of the present application, the above electronic device may be a computing device, such as a server; the electronic device may also be a storage device, such as a storage array, etc.; the electronic device may also be a network device, such as a switch.

Based on the same inventive concept, an embodiment of the present application further provides a lock management device. The management device is the lock management device 8011 in FIG. 8 . As shown in the figure, the lock management device 8011 may include: a processor 80111, a memory 80112, At least one communication interface (the first interface 80113 and the second interface 80114 are included in FIG. 3 as an example) and the bus 80115, and the processor 80111, the memory 80112, and the at least one communication interface communicate through the bus 80115.

The processor 80111 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the lock management method provided by the embodiments of the present application. The processor 80111 may One or more CPUs are included, such as CPU0 and CPU1.

At least one communication interface can be implemented using any transceiver-like device for communicating with other functional devices, devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (wireless local area network) area networks, WLAN), etc. The first interface 80113 is used to communicate with at least one processor core (eg 8013 ) in the processor 801 (eg CPU) of the electronic device, and the second interface is used to communicate with the interrupt controller in the electronic device.

Memory 802 may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically programmable Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory may be random access memory (RAM), which acts as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), Double data rate synchronous dynamic random access memory (double data date SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synchlink DRAM, SLDRAM) and direct Memory bus random access memory (direct rambus RAM, DR RAM). .

The memory 802 is used to store computer-executed instructions for executing the lock management method provided by the embodiments of the present application, wherein the memory 802 is used to store instructions for implementing three modular functions: a first communication instruction, a first processing instruction, and a third The two communication instructions are controlled and executed by the processor 801 . The processor 801 is configured to execute the computer-executed instructions stored in the memory 802, thereby implementing the lock management method provided in any possible implementation manner of the above one or more embodiments. The memory 802 shown in FIG. 8 is only a schematic diagram, and the memory may further include other functionalized instructions, which are not limited in this embodiment of the present application.

The lock management device is used for the functions performed by the corresponding subjects in the method embodiments described above in FIG. 1 to FIG. 6 , and details are not described here for brevity.

The application also provides an electronic device, as shown in FIG. 8 , the electronic device includes a processor 801 , a memory 802 , a communication interface 803 and a bus 804 , and the processor 801 , the memory 802 , and the communication interface 803 communicate through the bus 804 . The processor 801 includes a lock management device 8011 , an interrupt controller 8012 , a processor core 8013 and a bus 8014 . The interrupt controller 8012 may correspond to the interrupt distribution apparatus described above in FIG. 1 to FIG. 6 , and is configured to implement the operation steps of the method executed by the above-mentioned interrupt distribution apparatus. The electronic device 800 is used to implement the operation steps performed by the corresponding subjects in the methods described in FIG. 1 to FIG. 6 , which are not repeated here for brevity.

In addition to the data bus, the bus 804, the bus 8014 and the bus 80115 may also include various transmission media such as a power bus, a control bus, and a status signal bus for realizing the internal communication of the device or device. However, for clarity of illustration, the various buses are labeled as bus 804, bus 8014, and bus 80115 in the figures.

It should be noted that the number of each part in FIG. 8 does not constitute a limitation to the present application. For example, the processor core 8013 may include multiple ones. For the sake of brevity, only one is used as an example for labeling in the present application.

The foregoing electronic device 800 is used for the functions performed by the corresponding subjects in the foregoing method embodiments in FIG. 1 to FIG. 6 , and for brevity, details are not described herein again.

Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores instructions, and when the instructions are run on a computer, is used to execute any possible implementation manner in the foregoing embodiments The described lock management method.

Based on the same inventive concept, the embodiments of the present application provide a computer program or computer program product, when the computer program or computer program product is executed on a computer, the computer can realize the implementation as described in any possible implementation manner in the foregoing embodiments lock management method.

The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented in software, the above-described embodiments 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. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general purpose computer, special purpose computer, computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server, or data center Transmission to another website site, computer, server, or data center is by wire (eg, coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (eg, 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 such as a server, a data center, or the like that contains one or more sets of available media. The usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media. The semiconductor medium may be a solid state drive (SSD).

The above is only an exemplary embodiment of the present application, but the protection scope of the present application is not limited to this. Substitutions should be covered within the protection scope of this application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

A lock management method, comprising:

The lock management module obtains a lock application request from the first CPU core, and the lock application request is used for requesting to allocate a lock for the first program in the first CPU core;

The lock management module allocates a lock to the first program in response to the lock application request;

The lock management module sends a first signal to the interrupt distribution module, where the first signal is used to instruct the interrupt distribution module to stop distributing the interrupt to the first CPU core.
The method according to claim 1, wherein the lock management module determines the first CPU core from the at least one CPU core, comprising:

The lock management module determines the first CPU core from the at least one CPU core according to a preset rule
The method according to claim 1 or 2, wherein the first program is configured to maintain access to the critical section after acquiring the lock until the operation on the critical section is completed, and the critical section uses Used to indicate a program fragment that accesses a shared resource.
The method according to any one of claims 1 to 3, wherein after the lock management module allocates a lock to the first program, the method further comprises:

The lock management module releases the lock corresponding to the first program, and sends a second signal to the interrupt distribution module, where the second signal is used to instruct the interrupt distribution module to resume distributing interrupts to the first CPU core .
The method according to claim 4, wherein before the lock management module releases the lock corresponding to the first program, the method further comprises:

The lock management module obtains a lock release request from the first CPU core, and the lock release request is used to request to release the lock corresponding to the first program;

The lock management module sends a second signal to the interrupt distribution module, including:

The lock management module sends the second signal to the interrupt distribution module in response to the lock release request.
The method according to claim 4, wherein before the lock management module sends the second signal to the interrupt distribution module, the method further comprises:

The lock management module starts a timer module when allocating a lock to the first program;

The lock management module sends a second signal to the interrupt distribution module, including:

When the timer module times out, the lock management module sends the second signal to the interrupt distribution module.
A lock management device, comprising: a first communication unit, a distribution unit and a second communication unit;

The first communication unit is used to obtain a lock application request from the first CPU core, where the lock application request is used to request to allocate a lock for the first program in the first CPU core;

the allocation unit, configured to allocate a lock to the first program in response to the lock application request;

The second communication unit is configured to send a first signal to the interrupt distribution apparatus, where the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.
The apparatus according to claim 7, wherein the apparatus further comprises: a determining unit;

The first communication unit is further configured to obtain a lock application request from at least one CPU core before obtaining a lock application request from the first CPU core, where the lock application request from the at least one CPU core is used to request that all a program allocation lock in the at least one CPU core, the at least one CPU core including the first CPU core;

The determining unit is configured to determine the first CPU core from the at least one CPU core.
The apparatus according to claim 8, wherein the determining unit is specifically configured to determine the first CPU core from the at least one CPU core according to a preset rule.
The apparatus according to any one of claims 7 to 9, wherein the first program is configured to maintain access to the critical section after acquiring the lock until the operation on the critical section is completed, the A critical section is used to indicate a program fragment that accesses a shared resource.
The device according to any one of claims 7 to 10, characterized in that the device further comprises: a releasing unit, configured to release the first program after the allocating unit allocates the lock to the first program the corresponding lock;

The second communication unit is further configured to send a second signal to the interrupt distribution device, where the second signal is used to instruct the interrupt distribution device to resume distribution of the interrupt to the first CPU core.
The device according to claim 11, wherein the first communication unit is further configured to obtain a lock release from the first CPU core before the release unit releases the lock corresponding to the first program request, the lock release request is used to request to release the lock corresponding to the first program;

The second communication unit is configured to send the second signal to the interrupt distribution apparatus in response to the lock release request.
The device according to claim 11, wherein the device further comprises: a timing unit, configured to trigger a timer module when the allocation unit allocates a lock to the first program;

The second communication unit is configured to send the second signal to the interrupt distribution apparatus when the timer module times out.
A processor, comprising: at least one CPU core, a bus, a lock management device and an interrupt distribution device, wherein the at least one CPU core, the lock management device and the interrupt distribution device pass through the bus communication, the at least one CPU core includes a first CPU core;

The lock management device is configured to perform the operation steps of the lock management method according to any one of claims 1 to 6. .
The processor according to claim 14, wherein the interrupt distribution device is configured to receive the first signal sent by the lock management device; and in response to the first signal, stop sending to the first CPU Nuclear distribution interrupted.
An electronic device, comprising: a processor configured to execute the operation steps of the lock management method according to any one of claims 1 to 6.