A lock management method, device and equipment

Abstract

The present application provides a lock management method, device and equipment. The lock management method may include: the lock management module obtains a lock application request from the first CPU core, the lock application request is used 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 and allocates a lock for the first program; the lock management module sends a first signal to the interrupt distribution module, and the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core. In the present application, by stopping the distribution of interrupts to the first CPU core when the first program accesses the critical section, the first program can be uninterrupted by the interrupt after applying for the lock, and maintain access to the critical section until the execution of the critical section is completed, thereby reducing the waiting time for other programs to obtain the lock and reducing the consumption of CPU resources and memory resources.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a lock management method, device and equipment. Background Art

[0002] Multiple threads run in parallel in a multi-core central processing unit (CPU). 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 dispatching. A process can have one or more threads, and each thread shares the program's memory space. In order to ensure the program's secure access to a resource and maintain data consistency, parallel programs generally need to use a lock mechanism for synchronization, thereby ensuring the consistency of shared resource data during program execution.

[0003] Currently, after a thread acquires the lock, it can access the critical section and perform operations in the critical section. After completing the execution of the critical section, the thread releases the lock. At this time, other threads can obtain the lock to execute their own critical sections. Since only one thread can acquire the lock at the same time, only one thread can execute the critical section at a time. In this way, the critical section is guaranteed not to be executed in parallel by locking. However, after a thread acquires the lock, other threads need to wait for the lock to be released. In the process of waiting for the lock to be released, other threads will keep trying to acquire the lock, 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 for other threads will be, which will cause a long time of unnecessary consumption of CPU resources. Summary of the invention

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

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

[0006] In the present application, the above-mentioned lock management method may include: the lock management module obtains a lock application request from the first CPU core to request that a lock be allocated to a first program in the first CPU core; the lock management module responds to the lock application request and allocates a lock to the first program; the lock management module sends a first signal to the interrupt distribution module to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.

[0007] It can be understood that the step of the lock management module allocating a lock to the first program and the step of the lock management module sending a first signal to the interrupt distribution module can be executed in parallel, that is, the lock management module can respond to the lock application request, allocate a lock to the first program and send the first signal to the interrupt distribution module at the same time. Of course, the above two steps can also be executed in series, that is, the lock management module first allocates a lock to the first program and then sends the first signal to the interrupt distribution module.

[0008] In the present application, by stopping the distribution of interrupts to the first CPU core when the first program accesses the critical section, the first program can be kept from being interrupted by interrupts after applying for the lock, and can maintain access to the critical section until the execution of the critical section is completed. Since the distribution of interrupts to the first CPU core is stopped when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread for execution instead of the original program after the interrupt ends is avoided. Furthermore, after the first program completes the execution of the critical section, the lock management device releases the lock, so that other programs can try to acquire the lock, thereby reducing the waiting time for other programs to acquire the lock and reducing the consumption of CPU resources and memory resources.

[0009] In one possible implementation, the lock management module may first receive a lock application request sent from at least one CPU core in the first CPU to request that a lock be allocated to a program in each CPU core. Then, the lock management module determines the first CPU core from at least one CPU core, and then obtains a lock application request from the first CPU core.

[0010] It can be understood that the lock management module can determine the first CPU core from at least one CPU core according to preset rules. 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 at least one CPU core; or, the CPU core corresponding to a group of programs with the highest group priority in at least one CPU core; or, the core corresponding to the program at the head of the queue in a group of programs. Of course, the preset rules can also be other, which are not specifically limited in the embodiments of the present application.

[0011] In the present application, after the lock management module can obtain a lock application request sent by at least one CPU core, arbitration is required to confirm to which CPU core the lock is assigned, thereby ensuring that the critical section is uniquely accessed and the operation of the critical section is executed.

[0012] In another possible implementation, the first program is used to maintain access to the critical section after obtaining 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 obtaining the lock, the first program keeps accessing the critical section without being interrupted until the execution of the critical section is completed, thereby completing the execution of the critical section as soon as possible.

[0013] In another possible implementation, after allocating a lock to the first program, the lock management module may further 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 resume distributing interrupts to the first CPU core.

[0014] 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 executed in parallel, that is, the lock management module can respond to the lock application request, release the lock for the first program and send the second signal to the interrupt distribution module at the same time. Of course, the above two steps can also be executed 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.

[0015] 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, thereby reducing the waiting time for other programs to acquire the lock and reducing the consumption of CPU resources and memory resources; further, since the interrupt distribution to the first CPU core is restored when the first program completes the operation of executing the critical section, the CPU performance is guaranteed.

[0016] In another possible implementation, after the lock management module allocates a lock for the first program, if the first program completes access to the critical area, it can send a lock release request to the lock management module. In this way, the lock management module can obtain the lock release request from the first CPU core, 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 above lock release request and send a second signal to the interrupt distribution module to instruct the interrupt distribution module to resume distributing interrupts to the first CPU core.

[0017] It can be understood that after completing the access to the critical area, the first program can actively request to release the lock, and the lock management module can instruct the interrupt distribution module to resume distributing interrupts to the first CPU core so that other programs can try to acquire the lock as soon as possible, thereby reducing the waiting time for other programs to acquire the lock and reducing the consumption of CPU resources and memory resources.

[0018] In another possible implementation, when the lock management module allocates a lock to the first program, it can also start a timer module, that is, the lock management module sets 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 area, the lock management module will send a second signal to the interrupt distribution module to indicate that it will resume distributing interrupts to the first CPU core.

[0019] 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 section, the first program can continue to access the critical section; if the first program completes the access to the critical section, the first program can send a lock release request to the lock management module to request the release of the lock.

[0020] In the present application, the lock management module sets a period of time by itself, during which the first program accesses the critical section. At the end of this period of time, regardless of whether the first program completes the access to the critical section, the managed module will request to resume distributing interrupts to the first CPU core to ensure CPU performance.

[0021] In another possible implementation manner, the first program is a user-mode program.

[0022] In another possible implementation, the first CPU includes at least one CPU core, a lock management module, and an interrupt distribution module, the at least one CPU core, the lock management module, and the 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 using a hardware module.

[0023] In a second aspect, the present application provides a lock management device, which can be a chip or system on chip in a processor, or a functional module in a processor for implementing the method described in the first aspect or any possible implementation method of the first aspect. 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 a first CPU core, the lock application request is used to request to allocate a lock for a first program in the first CPU core; the allocation unit is used to respond to the lock application request and allocate a lock for the first program; the second communication unit is used to send a first signal to an interrupt distribution device, the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.

[0024] In the present application, the lock management device stops distributing interrupts to the first CPU core when the first program accesses the critical section, so that after applying for the lock, the first program can maintain access to the critical section without being interrupted by the interrupt until the execution of the critical section is completed. Since the interrupt is stopped from being distributed 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 after the interrupt ends is avoided. Furthermore, after the first program completes the execution of the critical section, the lock management device releases the lock so that other programs can try to acquire the lock, thereby reducing the time other programs wait for acquisition and reducing the consumption of CPU resources and memory resources. .

[0025] In one possible implementation, the above-mentioned device also includes: a determination unit; then, the first communication unit is also used to obtain a lock application request from at least one CPU core before obtaining the lock application request from the first CPU core, and the lock application request from at least one CPU core is used to request to allocate a lock for a program in at least one CPU core, and the at least one CPU core includes the first CPU core; the determination unit is used to determine the first CPU core from the at least one CPU core.

[0026] In another possible implementation manner, the above-mentioned determination unit is specifically configured to determine the first CPU core from at least one CPU core according to a preset rule.

[0027] In another possible implementation, 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.

[0028] In another possible implementation, the above-mentioned device also includes: a release unit, used to release the lock corresponding to the first program after the allocation unit allocates the lock to the first program; a second communication unit, also used to send a second signal to the interrupt distribution device, and the second signal is used to instruct the interrupt distribution device to resume distributing interrupts to the first CPU core.

[0029] In another possible implementation, the first communication unit is also used 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 the release of the lock corresponding to the first program; the second communication unit is used to respond to the lock release request and send a second signal to the interrupt distribution device.

[0030] In another possible implementation, the device further includes: a timing unit, configured to trigger a timer module when the allocation unit allocates a lock to the first program; and a second communication unit, configured to send a second signal to the interrupt distribution device when the timer module times out.

[0031] In another possible implementation manner, the first program is a user-mode program.

[0032] 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, the lock management device and the interrupt distribution device communicate through the bus, and at least one CPU core includes a first CPU core; a lock management device, for executing the lock management method described in any possible implementation manner of the first party or the first aspect above.

[0033] In a possible implementation, the interrupt distribution device is used to receive a first signal sent by the lock management device; and in response to the first signal, stop distributing interrupts to the first CPU core.

[0034] In another possible implementation, 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 interrupts to the first CPU core.

[0035] In a fourth aspect, the present application provides an electronic device, comprising: a processor, the processor being used to execute the lock management method described in any possible implementation of the first party or the first aspect.

[0036] In the present application, the electronic device may be a computing device, a storage device, a network device, etc.

[0037] 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 being coupled to the memory, the first interface and the second interface respectively, the processor communicating with at least one CPU core through the first interface, and communicating with an interrupt distribution device through the second interface, the processor being configured to read and execute instructions in the memory to implement the lock management method described in any possible implementation manner of the first party or the first aspect above.

[0038] In a sixth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer, the lock management method is used to execute the lock management method as described in the first aspect or any possible implementation method of the first aspect.

[0039] In a seventh aspect, the present application provides a computer program or a computer program product. When the computer program or the computer program product is executed on a computer, the computer implements the lock management method as described in the first aspect or any possible implementation manner of the first aspect.

[0040] 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 achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments of the present application will be described below.

[0042] Figure 1 A schematic diagram of a lock usage access method in an embodiment of the present application;

[0043] Figure 2 This is a timing diagram of the operation of executing a critical section by thread A in an embodiment of the present application;

[0044] Figure 3 A schematic diagram of the structure of a processor in an embodiment of the present application;

[0045] Figure 4 It is a structural schematic diagram of a lock management device and an interrupt distribution device in an embodiment of the present application;

[0046] Figure 5 A flowchart of a lock management method in an embodiment of the present application;

[0047] Figure 6 A schematic diagram of the logical structure of the hardware queue in the embodiment of the present application;

[0048] Figure 7 is a schematic diagram of the structure of a lock management device in an embodiment of the present application;

[0049] Figure 8 The figure is a schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application.

[0051] Figure 1 This is a schematic diagram of a lock access method in an embodiment of the present application, see Figure 1 As shown in the figure, after thread A acquires the lock, it will execute the operation of its own critical section and release the lock after the execution of its critical section is completed. Then, other threads, such as thread B or thread C, can acquire the lock and execute their own critical section code after acquiring the lock. However, since at most only one thread can acquire the lock, at most only one thread can execute the critical section at a time. In this way, the critical section is protected from parallel execution by locking.

[0052] It should be noted that in the 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 an operation in a critical section, other programs must wait to ensure that these shared resources are mutually exclusive.

[0053] In the development and operation of multi-program software, the locks that a program can obtain are used to control resource access, and may include spin locks, mutex locks, improved mutex locks, etc. Of course, the above locks may also be other locks derived from spin locks and / or mutex locks, which are not specifically limited in the embodiments of the present application.

[0054] It should be noted that the "program" mentioned in the embodiments of the present application can be understood as a process or thread running in the CPU core, and the embodiments of the present application do not make any specific limitations.

[0055] The following uses the example of a thread applying for or releasing a spin lock to illustrate the working mechanism of the above lock.

[0056] A spin lock is a lock used for fast synchronization between multiple threads. It is widely used when multiple threads need fast mutual exclusive access, especially when the critical section is short. Using a spin lock can effectively reduce the impact of the lock's own overhead on application performance.

[0057] For example, the logic of a typical spinlock acquisition function can be as follows:

[0058] spin_lock_get{}{

[0059] while(failed to read and write public variables);

[0060] }

[0061] Among them, the above-mentioned public variables are equivalent to flags, and the operations of reading and writing public variables are generally to set or check the value of the public variables; if the variable value is set, it means that the lock is occupied, and clearing the variable value means that the lock is free and can be used by other threads. If the thread fails to acquire the lock, it will continue to try to acquire the lock in a loop until it successfully acquires the lock. In other words, when a thread fails to acquire the spin lock, the thread will continue to try 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 complicated thread scheduling processes; at the same time, the disadvantage of this is also obvious, that is, while the current thread is waiting to acquire the lock, the CPU resources will be occupied all the time, and it cannot switch to execute the tasks of other threads, which is a meaningless waste of CPU resources, especially under the condition of long waiting time.

[0062] Furthermore, since the program acquires the spin lock by reading and writing public memory variables, when the program is waiting to acquire the spin lock, it will not only occupy CPU resources, but also unnecessary memory bandwidth resources. In order to reduce the consumption of CPU and memory resources by the waiting thread, the thread holding the spin lock needs to complete the critical section operation as soon as possible and then release the spin lock. However, the execution time of a thread in the critical section, in addition to depending on the logical complexity of the critical section, will also be affected by the preemptive operation of other codes. For example, Figure 2 This is a timing diagram of the operation of executing the critical section of thread A in the embodiment of the present application, see Figure 2 As shown in the figure, during the execution of the critical section of thread A, the CPU resources are preempted by a program with a higher priority, and the CPU core responds to the interrupt first. Then, thread A must wait until the interrupt processing is completed before it can continue to execute the critical section. The time for thread A to release the lock will also be delayed accordingly. The waiting time of other threads, such as thread B and thread C, will also be extended, resulting in a meaningless waste of CPU resources, especially when the waiting time is long.

[0063] In addition, according to the different permission states in which the expected program is running, the program can generally be divided into user state program and kernel state program. The user state program refers to the program running under the lowest permission of the CPU, while the kernel state program can narrowly refer to the program that needs to run under the highest permission of the CPU, and can also refer to the program running under a higher permission than the user state permission. In conjunction with the embodiment of the present application, the instruction to access the memory variable is a low-privilege instruction, so the user state program (user state thread or user state process) can be executed directly, but the operations such as prohibiting interrupts and prohibiting preemption are high-privilege operations, which cannot be executed directly in the user state program, but require the system to call the kernel state program to execute, but the system call is a very time-consuming operation, which usually takes hundreds of nanoseconds or even microseconds to complete. Then, in the process of the system call, other programs may be preempted, thereby affecting the execution time of the program to the critical section.

[0064] Furthermore, if the program is interrupted while executing operations in the critical section, then after the interrupt ends, the CPU core may select a higher priority program to execute instead of the original program, resulting in a deadlock problem.

[0065] Then, in order to solve the above problems, an embodiment of the present application provides a processor, such as a CPU, which can be set in a device such as a computing device, a storage device, a network device, etc. Figure 3 This is a schematic diagram of the hardware structure of the processor in the embodiment of the present application, see Figure 3As shown by the solid line, the processor 100 may include: at least one processor core 101, a bus 102, a lock management device 103, and an interrupt distribution device 104, wherein the processor core 101 includes a CPU core, and each processor core 101, lock management device 103, and interrupt distribution device 104 communicate through the bus 102.

[0066] In some possible implementations, see Figure 3 As shown by the middle dotted line, the lock management device 103 and the interrupt distribution device 104 can also communicate directly.

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

[0068] The lock management device is used to obtain a lock application request from the first CPU core; in response to the lock application request, allocate a lock to the first program in the first CPU core, and send a first signal to the interrupt distribution device to instruct the interrupt distribution device to stop distributing interrupts to the first CPU core.

[0069] In other embodiments of the present application, the lock management device is further used 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 interrupts to the first CPU core.

[0070] The above-mentioned interrupt distribution device is used to receive the first signal sent by the lock management device; respond to the first signal and stop distributing interrupts to the first CPU core.

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

[0072] Then, from the perspective of the first CPU core, the first CPU core applies for a lock from 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 the first CPU core releases the lock, the lock management device notifies the interrupt distribution device to resume distributing interrupts to the first CPU core.

[0073] In practical applications, the lock management device can be implemented based on a hardware queue, a ring, a register storage flag or other logic. The lock management device can be implemented using programmable devices, such as application specific integrated circuits (ASIC), register transfer level circuits (RTL), field programmable gate arrays (FPGA), etc. Of course, depending on the type of CPU, other programmable devices can also be used for implementation, or the lock management device can also be implemented using a logic circuit, which is not specifically limited in the embodiments of the present application. The interrupt distribution device can be implemented based on the structure of the interrupt controller of the CPU. The interrupt distribution device can implement the above functions using a hardware structure, or it can implement the above functions by software, for example, using any one of the processor cores in the processor 100 to implement the above functions.

[0074] In the embodiments of the present application, Figure 4 This is a schematic diagram of the structure of the lock management device and the interrupt distribution device in the embodiment of the present application, see Figure 4 As shown by the solid line, the lock management device 103 may include: a lock management module 401, a first interface module 402, and a second interface module 403. 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 can be implemented by an independent programmable device, a logic circuit, or other hardware module.

[0075] Still see Figure 4 As shown, the interrupt distribution device 104 may include: an interrupt distribution module 411, a third interface module 412 and a fourth interface module 413; the third interface module is used to communicate with the lock management device, and the fourth interface module is used to communicate with at least one CPU core to perform interrupt distribution. The third interface module and the second interface module may communicate via a bus or directly.

[0076] The first interface module, the second interface module, the third interface module and / or the fourth interface module may be implemented by, for example, a transceiver circuit, an optical transceiver, etc.

[0077] It should be noted that in the 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 mutex lock. Of course, other locks derived from spin locks and / or mutex locks may also be used, and no specific limitation is made to this.

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

[0079] The interrupt distribution module stops or resumes the interrupts distributed to the first CPU core as maskable interrupts, which are generated by peripheral devices with interrupt capabilities. That is, after the first program acquires the lock, it notifies the interrupt distribution device to stop or resume the distribution of maskable interrupts to the first CPU core.

[0080] The following takes a spin lock as an example, and combines the structure of the above-mentioned CPU to illustrate a lock management method provided in an embodiment of the present application.

[0081] Figure 5 This is a flowchart of the lock management method in the embodiment of the present application, see Figure 6 As shown by the solid line in , the method may include:

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

[0083] When the first program running in the first CPU core needs to access the critical section, the first CPU core sends a lock application request to the lock management module through the first interface module to request the lock management module to allocate a lock for the first program so that the first program can access the critical section and perform operations in the critical section.

[0084] In some possible implementations, while the first CPU core is requesting a lock, other cores of the CPU may also send a lock request to the lock management module through the first interface module. That is, the first interface module may be accessed by at least one CPU core at the same time and receive a lock request from at least one CPU core.

[0085] S502: The lock management module responds to the lock application request and allocates a lock for the first program.

[0086] In the case where 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.

[0087] In actual applications, in addition to the first program in the first CPU core requesting access to the critical section, there may also be other threads sending lock application requests to the lock management module at the same time. Then, after the lock management module obtains the lock application request sent by at least one CPU core, it needs to perform arbitration to confirm which CPU core the lock is assigned to. Assuming that the lock management module arbitrates and decides 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 uniquely access the critical section and perform operations in the critical section.

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

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

[0090] While S502 is being executed or after S502 is executed, the lock management module communicates with the third interface module through the second interface module, and sends a first signal to the interrupt distribution module to notify the interrupt distribution module to stop distributing interrupts to the first CPU core, so that the first program can maintain access to the critical area without being disturbed by the interrupt, complete the operation on the critical area as soon as possible, reduce the waiting time for other threads to obtain the lock, and reduce the consumption of CPU resources and memory resources.

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

[0092] In some possible implementations, S502 and S503 may be executed sequentially during the execution process, such as executing S502 first and then S503, or executing S503 first and then S502; of course, S502 and S503 may also be executed at the same time, and the execution order of S502 and S503 is not specifically limited in the embodiments of the present application.

[0093] At this point, the lock application process is completed.

[0094] In some possible implementations, after the first program completes execution of the critical section, it needs to release the lock so that other programs can acquire the lock as soon as possible. Figure 6 As shown by the dotted line in FIG, after S504, the lock management method may further include:

[0095] S505: The lock management module releases the lock corresponding to the first program;

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

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

[0098] In some possible implementations, S505 and S506 may be executed sequentially during the execution process, such as executing S505 first and then S506, or executing S506 first and then S505; of course, S505 and S506 may also be executed at the same time, and the execution order of S505 and S506 is not specifically limited in the embodiments of the present application.

[0099] S507: The interrupt distribution module responds to the second signal and resumes distributing interrupts to the first CPU core.

[0100] 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 while releasing the lock or after releasing the lock, so as to instruct the interrupt distribution module to resume distributing interrupts to the first CPU core. The interrupt distribution module responds to the second signal and resumes distributing interrupts to the first CPU. Then, when the first CPU core receives the interrupt distributed by the interrupt distribution module, it may respond to the interrupt and process the interrupt.

[0101] In some possible embodiments, after completing the execution of the critical section, the above-mentioned first program can request the lock management module to release the lock assigned to the first program. Then, S505 may include: the lock management module obtains a lock release request from the first CPU core, and the lock management module responds to the lock release request to release the lock corresponding to the first program.

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

[0103] Accordingly, before, after or simultaneously with executing S505 , the lock management module responds to the lock release request and sends a second signal to the interrupt distribution module to instruct the interrupt distribution module to resume distributing interrupts to the first CPU core.

[0104] In some possible embodiments, in addition to instructing the interrupt distribution module to resume distributing interrupts 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 interrupts to the first CPU core. Figure 4 As shown by the middle dotted line, the lock management device 103 may further include: a timer module 404; here, the duration of the timer module 404 may be understood as the duration expected to be used by the first program to execute operations in the critical section, and the specific value of the duration may be set according to the performance of the CPU, the requirements of the operating system, etc., and is not specifically limited in the embodiments of the present application.

[0105] In practical applications, the timer module can be implemented by, but is not limited to, a timer circuit or a timer program, and the embodiments of the present application do not make specific limitations.

[0106] Then, after the lock management module allocates a 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 interrupts to the first CPU. 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.

[0107] 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.

[0108] At this point, the lock release process is completed.

[0109] In some possible implementations, during the process of allocating a lock to the first program through S502, the lock management module can record which CPU core's program the lock is allocated to, such as the first CPU core. In this way, when the lock management module executes S503, it can instruct the interrupt distribution module to stop distributing interrupts to the recorded CPU core, i.e., the first CPU core.

[0110] Correspondingly, in the process of releasing the lock for the first program through S505, the lock management module can record for which CPU core the program has released the lock, such as the first CPU core. In this way, when executing S506, the lock management module can instruct the interrupt distribution module to resume distributing interrupts to the recorded CPU core, i.e., the first CPU core.

[0111] Through the above-mentioned lock application process and lock release process, the first program in user mode can maintain access to the critical section without being interrupted by interrupts after applying for the lock until the execution of the critical section is completed. Since the interrupt is stopped from being distributed to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread to execute instead of the original program after the interrupt ends is avoided. Furthermore, after the first program completes the execution of the critical section, the lock management device releases the lock so that other programs can try to acquire the lock, thereby reducing the time other programs have to wait for acquisition and reducing the consumption of CPU resources and memory resources. Furthermore, since the interrupt is stopped from being distributed to the first CPU core when the first program accesses the critical section, the deadlock problem of selecting a higher priority thread to execute instead of the original program after the interrupt ends is avoided.

[0112] In some possible embodiments, the execution process of the above S501 to S507 is described by taking the lock management device implemented based on hardware queue logic as an example.

[0113] Figure 6 This is a schematic diagram of the logical structure of the hardware queue in the embodiment of the present application, see Figure 6As shown, the hardware queue read-write interface allows multiple CPU cores to access it simultaneously, and the read-write interface arbitrates the order of read and write access of multiple CPU cores to the queue content, so that the final reading and writing of data to the queue storage area is serial writing (understandably, all read processes are serial, all write processes are serial, and there can be a write process while reading). When a CPU core writes a piece of data to the queue, there will be one more piece of data in the queue storage, and the newly added data is located at the tail of the valid data in the queue storage area; when a CPU core requests to read a piece of data from the queue, there will also be one piece of data reduced in the queue storage, and the reduced data is the data at the head of the valid data previously located in the storage area. The data in the queue storage area will always maintain a relative order according to the order of writing. When the queue reduces one piece of 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 CPU core write operation will receive a full feedback message and need to wait for re-writing; if the queue storage area has no valid data, that is, it is in an empty state, the subsequent CPU core read operation will receive an empty feedback message and need to wait for re-reading.

[0114] When the hardware queue is initialized, a valid data is stored in the queue. First, at least one CPU core in the CPU simultaneously accesses the read interface and sends a lock application request (here, the lock application request can be understood as a read signal), and the read interface arbitrates to decide which CPU core the lock is assigned to. For example, the read interface can sort the programs in the CPU core according to priority, and decide to allocate a lock to the first program with the highest priority. Accordingly, the read interface responds to the lock application request of the first CPU core, and the first program reads the valid data at the head of the queue; or, the read interface can sort the lock application requests sent by the CPU core in chronological order, and decide to allocate a lock to the first program that first sends a lock application request to the read interface. Accordingly, the read interface responds to the lock application request of the first 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 the program is assigned a lock to. For example, the read interface can also decide to allocate a lock to a group of programs with the highest group priority, or to allocate a lock to the first program at the head of the queue in a group of programs, etc., which is not specifically limited in the embodiments of the present application. Then, while allocating a 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.

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

[0116] Furthermore, 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 queue after the move remains unchanged.

[0117] In actual applications, the above-mentioned read interface and write interface can be physically separated or combined. The functional module in the read interface and the write interface that communicates with the CPU core can correspond to the above-mentioned first interface module, the functional module that communicates with the interrupt distribution device can correspond to the above-mentioned second interface module, and the functional module that performs arbitration decision-making in the read interface can correspond to the above-mentioned lock management module.

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

[0119] A flag is set in the register to indicate the state of the lock. If the flag is at position 1, it indicates that the lock has not been allocated and can be obtained. On the contrary, if the flag is at position 0, the flag lock has been allocated and cannot be obtained. First, when the register is initialized, the flag is set to position 1. First, at least one CPU core in the CPU accesses the register at the same time and sends a lock application request. The register arbitrates to determine which program in which CPU core the lock is allocated. For example, the register can sort the programs in the CPU core according to priority, and decide to allocate a 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 position 0, and informs the first CPU core, or the register can sort the lock application requests sent by the CPU core in chronological order, and decide to allocate a lock to the first program that first sends a lock application request to the register. Accordingly, the read interface responds to the lock application request of the first CPU core, sets the flag to position 0, and informs the first CPU core. Of course, the register can also use other arbitration rules to decide which program in which CPU core the lock is allocated. For example, the register can also decide to allocate a lock to a group of programs with the highest group priority, or allocate a lock to the first program at the head of the queue in a group of programs, etc., which is not specifically limited in the embodiments of the present application. Then, while allocating the lock to the first program, the register 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.

[0120] 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 position to 1 to complete the lock release. At the same time, the write interface can also send a second signal to the interrupt distribution device to instruct the interrupt distribution device to resume distributing interrupts to the first CPU core.

[0121] From the above, we can see that when other programs access the register, if the flag bit read is 0, it means that the lock has been allocated, and other programs wait and continue to try to acquire the lock; if the flag bit read is 1, it means that the lock has not been allocated, and the program can acquire the lock.

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

[0123] In some possible implementations, the 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. Since the kernel-mode program can execute operations such as disabling interrupts and disabling preemption, but the kernel-mode program disables interrupts or disabling preemption by not responding to interrupts, which may delay the response to interrupts and increase the time consumption of interrupt response, then, for the first kernel-mode program, the method described in S501 to S505 may be executed, so that the interrupt distribution device may distribute interrupts with higher priority to other CPU cores for processing after stopping distributing interrupts to the first CPU core, so that interrupts can be responded to in a timely manner and the real-time performance is improved.

[0124] 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 can 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 that these programs can be executed as quickly as possible, improving real-time performance.

[0125] Based on the same inventive concept, the embodiment of the present application also provides a lock management device, which can be a chip or system on chip in a processor, or a functional module in a processor for implementing the method described in any possible implementation method in the above embodiments. Figure 7 The structure of the lock management device in the embodiment of the present application is shown in FIG. Figure 1 , see Figure 7As shown, the lock management device 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 and allocate a lock for the first program; the second communication unit 703 is used to send a first signal to the interrupt distribution device, and the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core.

[0126] In an embodiment of the present application, the lock management device stops distributing interrupts to the first CPU core when the first program accesses the critical section, so that after applying for the lock, the first program can maintain access to the critical section without being interrupted by the interrupt until the execution of the critical section is completed. Since the interrupt is stopped from being distributed 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 after the interrupt ends is avoided. Furthermore, after the first program completes the execution of the critical section as quickly as possible, the lock management module releases the lock so that other programs can try to acquire the lock, reducing the time other programs wait for acquisition and reducing the consumption of CPU resources and memory resources.

[0127] It should be understood that the device 700 of the embodiment of the present application can be implemented by an application specific integrated circuit (ASIC) or a programmable logic device (PLD), and the PLD can be a complex programmable logical device (CPLD), a field programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. It can also be implemented by software. Figures 1 to 7 When the method shown in , the device 700 and its various modules may also be software modules.

[0128] In some possible implementations, the above-mentioned device also includes: a determination unit; then, the first communication unit is also used to obtain a lock application request from at least one CPU core before obtaining the lock application request from the first CPU core, and the lock application request from at least one CPU core is used to request to allocate a lock for a program in at least one CPU core, and the at least one CPU core includes the first CPU core; the determination unit is used to determine the first CPU core from the at least one CPU core.

[0129] In some possible implementations, the above-mentioned determination unit is specifically configured to determine the first CPU core from at least one CPU core according to a preset rule.

[0130] 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 a shared resource.

[0131] In some possible embodiments, the above-mentioned device also includes: a release unit, used to release the lock corresponding to the first program after the allocation unit allocates the lock to the first program; a second communication unit, also used to send a second signal to the interrupt distribution device, and the second signal is used to instruct the interrupt distribution device to resume distributing interrupts to the first CPU core.

[0132] In some possible implementations, the first communication unit is also used 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 the release of the lock corresponding to the first program; the second communication unit is used to respond to the lock release request and send a second signal to the interrupt distribution device.

[0133] In some possible implementations, the above-mentioned device further includes: a timing unit, configured to trigger a timer module when the allocation unit allocates a lock to the first program; and a second communication unit, configured to send a second signal to the interrupt distribution device when the timer module times out.

[0134] In some possible implementations, the first program is a user-mode program.

[0135] The first communication unit can be connected with Figure 4 Corresponding to the first interface module in, the second communication unit can be connected to Figure 4 Corresponding to the second interface module in; the allocation unit, determination unit, release unit and timing unit can be one or more processors.

[0136] Based on the same inventive concept, an embodiment of the present application further provides an electronic device, including: a processor, the processor being used to execute the lock management method described in any possible implementation manner of the above embodiment.

[0137] In the embodiments of the present application, the 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, etc.

[0138] Based on the same inventive concept, the embodiment of the present application also provides a lock management device, the management device is as follows: Figure 8 The lock management device 8011, as shown in the figure, may include: a processor 80111, a memory 80112, at least one communication interface ( Figure 3The figure is merely an example of an example including a first interface 80113 and a second interface 80114) and a bus 80115, and the processor 80111, the memory 80112, and at least one communication interface communicate through the bus 80115.

[0139] 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 in the embodiment of the present application. Processor 80111 may include one or more CPUs, such as CPU0 and CPU1.

[0140] 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 networks (WLAN), etc. Among them, the first interface 80113 is used to communicate with at least one processor core (e.g., 8013) in the processor 801 (e.g., CPU) of the electronic device, and the second interface is used to communicate with an interrupt controller in the electronic device.

[0141] The memory 802 may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. Among them, the nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0142] The memory 802 is used to store computer-executable instructions for executing the lock management method provided in the embodiment of the present application, wherein the memory 802 stores instructions for implementing three modular functions: a first communication instruction, a first processing instruction, and a second communication instruction, and is controlled to be executed by the processor 801. The processor 801 is used to execute the computer-executable instructions stored in the memory 802, thereby implementing the lock management method provided in any possible implementation manner in one or more of the above embodiments. Figure 8 The memory 802 shown in the figure is only a schematic diagram, and the memory may also include other functional instructions, which are not limited in the embodiments of the present application.

[0143] Lock management device for the above Figures 1 to 6 For the sake of brevity, the functions performed by the corresponding subjects in the above method embodiments are not described in detail here.

[0144] The present application also provides an electronic device, such as Figure 8 As shown, the electronic device includes a processor 801, a memory 802, a communication interface 803 and a bus 804. 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 lock management device 8011, the interrupt controller 8012 and the processor core 8013 are connected through the bus 8014. The interrupt controller 8012 may correspond to the above Figures 1 to 6 The interrupt distribution device described in the foregoing is used to implement the operation steps of the method performed by the interrupt distribution device described above. The electronic device 800 is used to implement the foregoing Figures 1 to 6 For the sake of brevity, the operation steps performed by the corresponding subjects in the method are not repeated here.

[0145] In addition to the data bus, the bus 804, bus 8014 and bus 80115 may also include various transmission media for realizing internal communication of devices or equipment, such as a power bus, a control bus and a status signal bus. However, for the sake of clarity, various buses are labeled as bus 804, bus 8014 and bus 80115 in the figure.

[0146] It is worth mentioning that Figure 8 The number of each part does not constitute a limitation of the present application. For example, the processor core 8013 may include multiple parts. For the sake of simplicity, the present application only uses one as an example for labeling.

[0147] The electronic device 800 is used for the Figures 1 to 6 For the sake of brevity, the functions performed by the corresponding subjects in the above method embodiments are not described in detail here.

[0148] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer, the lock management method described in any possible implementation manner in the above embodiments is executed.

[0149] Based on the same inventive concept, an embodiment of the present application provides a computer program or a computer program product. When the computer program or the computer program product is executed on a computer, the computer implements the lock management method as described in any possible implementation manner in the above embodiments.

[0150] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above embodiments can 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, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid state drive (SSD).

[0151] The above is only an exemplary embodiment of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A lock management method, characterized in that: include: The lock management module obtains a lock application request from the first CPU core, where the lock application request is used to request allocation of a lock for a first program in the first CPU core; The lock management module allocates a lock for 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 interrupts to the first CPU core; After the lock management module allocates a lock for the first program, the method further includes: 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.

2. The method according to claim 1, characterized in that The lock management module determines the first CPU core from at least one CPU core according to a preset rule.

3. The method according to claim 1 or 2, characterized in that: The first program is used to keep 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.

4. The method according to claim 1, characterized in that Before the lock management module releases the lock corresponding to the first program, the method further includes: The lock management module obtains a lock release request from the first CPU core, where 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.

5. The method according to claim 1, characterized in that Before the lock management module sends the second signal to the interrupt distribution module, the method further includes: When the lock management module allocates a lock for the first program, the timer module is started; 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.

6. A lock management device, characterized in that: include: 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 a first CPU core, where the lock application request is used to request allocation of a lock for a first program in the first CPU core; The allocation unit is used to allocate a lock for the first program in response to the lock application request; The second communication unit is used to send a first signal to the interrupt distribution device, where the first signal is used to instruct the interrupt distribution module to stop distributing interrupts to the first CPU core; The device further comprises: a releasing unit, configured to release the lock corresponding to the first program after the allocating unit allocates the lock to the first program; The second communication unit is further used to send a second signal to the interrupt distribution device, where the second signal is used to instruct the interrupt distribution device to resume distributing interrupts to the first CPU core.

7. The device according to claim 6, characterized in that The device further comprises: a determination unit; The first communication unit is further configured to obtain a lock application request from at least one CPU core before obtaining the lock application request from the first CPU core, wherein the lock application request from the at least one CPU core is used to request allocation of a lock for a program in the at least one CPU core, and the at least one CPU core includes the first CPU core; The determining unit is used to determine the first CPU core from the at least one CPU core.

8. The device according to claim 7, characterized in that The determining unit is specifically configured to determine the first CPU core from the at least one CPU core according to a preset rule.

9. The device according to any one of claims 6 to 8, characterized in that The first program is used to keep 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.

10. The device according to claim 6, characterized in that 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, wherein the lock release request is used to request the release of the lock corresponding to the first program; The second communication unit is used to send the second signal to the interrupt distribution device in response to the lock release request.

11. The device according to claim 6, characterized in that 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 used to send the second signal to the interrupt distribution device when the timer module times out.

12. A processor, characterized in that: include: 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 communicate via the bus, and the at least one CPU core includes a first CPU core; The lock management device is used to execute the operation steps of the lock management method according to any one of claims 1 to 5.

13. The processor according to claim 12, characterized in that The interrupt distribution device is used to receive the first signal sent by the lock management device; in response to the first signal, stop distributing interrupts to the first CPU core.

14. An electronic device, characterized in that: include: A processor, wherein the processor is used to execute the operation steps of the lock management method according to any one of claims 1 to 5.

Images