A method and device for obtaining thread read / write blocking information

By integrating detection points in read-write lock interfaces to automatically detect and output blocking information for threads holding locks over a threshold time, the method enhances efficiency and reduces user expertise requirements in identifying thread blocking issues.

CN115543642BActive Publication Date: 2025-07-15XFUSION DIGITAL TECH CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202210988150.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-17
Publication Date
2025-07-15
Estimated Expiration
2042-08-17

AI Technical Summary

Technical Problem

In the read-write lock scenario, the process of obtaining thread blocking information is complicated, requires high professional technical requirements, and cannot be automatically identified and updated, resulting in low efficiency and low accuracy.

Method used

By registering a detection point at the application interface of the read and write lock, the time when the thread acquires the lock is automatically recorded, and blocking information is output when the lock hold time exceeds the threshold, reducing log processing and improving the efficiency of obtaining thread blocking information.

Benefits of technology

It realizes that no complex configuration and secondary processing is required, reduces professional technical requirements, and improves the efficiency and accuracy of obtaining thread blocking information.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115543642B_ABST
    Figure CN115543642B_ABST
Patent Text Reader

Abstract

The present application discloses a method and device for obtaining thread read-write blocking information, which relates to the field of computing devices, and reduces the professional technical requirements for users while efficiently and accurately obtaining thread blocking information. The specific solution is as follows: obtain the time point when the thread that calls the read-write lock successfully obtains the read-write lock through the probe point registered at the application interface of the read-write lock; determine the holding time of the thread currently holding the read-write lock; if the holding time of the first thread is greater than or equal to the first threshold, output the blocking information of the first thread.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computing devices, and in particular, to a method and device for obtaining thread read / write blocking information. Background Art

[0002] A read-write lock is a lock that separately locks and controls the read and write operations of shared resources to improve the concurrency of read operations. Therefore, it is widely used in scenarios where reads are much more frequent than writes. In scenarios where a read-write lock is applied, only read operations are allowed to be concurrent (i.e., access the shared resource simultaneously).

[0003] When an operation holds a lock to access a shared resource, the lock requests of operations that cannot be concurrent with it will be blocked. Abnormally long lock holding will affect the service corresponding to the thread whose lock request is blocked. Therefore, it is necessary to output the blocking information of the thread to indicate the behavior of the thread during the lock occupancy, for observing the read-write lock, locating and determining the cause of the block, facilitating handling exceptions from a business perspective, and improving the user's business experience. Summary of the Invention

[0004] This application provides a method and device for obtaining thread read / write blocking information, which improves the efficiency of obtaining thread blocking information.

[0005] To achieve the above object, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, a method for obtaining thread read / write blocking information is provided. The method may include: obtaining, through a probe point registered at the application interface of the read-write lock, the time point when the thread that calls the read-write lock successfully obtains the read-write lock; determining the lock holding time of the thread currently holding the read-write lock; if the lock holding time of a first thread is greater than or equal to a first threshold, outputting the blocking information of the first thread; the first thread is any thread currently holding the read-write lock.

[0007] Through the solution provided by this application, a probe point is registered at the application interface of the read-write lock. Through this probe point, the time point when the thread successfully obtains the read-write lock can be automatically obtained, and then the lock holding time of the thread can be accurately obtained. When the lock is held for too long, the blocking information of the thread is automatically output. The whole process is automatically implemented, without the need for secondary processing of the logs, reducing the amount of output logs, and greatly improving the efficiency of obtaining thread blocking information.

[0008] Furthermore, in the solution provided by the embodiments of this application, the whole process is automatically implemented. Users do not need to perceive a large number of interface files, nor do they need to understand the implementation mechanism of the system, greatly reducing the professional technical requirements for users.

[0009] In a possible implementation, a probe point registered through the application interface of a read-write lock is used to obtain the time point when the thread that calls the read-write lock successfully obtains the read-write lock. Specifically, it can be implemented as follows: The instruction information of the application interface is detected through this probe point; when at a first time point, the probe point detects first instruction information, the first time point is used as the time point when a second thread successfully obtains the read-write lock. Among them, the first instruction information is used to allocate the read-write lock to the second thread.

[0010] In a possible implementation, the holding time of the thread currently holding the read-write lock is determined. Specifically, it can be implemented as follows: At the detection moment, the holding time of the thread currently holding the read-write lock at the detection moment is determined. The holding time of a thread is the detection moment minus the time point when the thread successfully obtains the read-write lock. The detection moment is configured according to the actual scenario to obtain the blocking information of the thread as required.

[0011] In a possible implementation, multiple detection moments are set periodically. By performing detections periodically, the blocking information of the thread can be obtained in a timely manner to solve the system blocking problem.

[0012] In a possible implementation, the method provided in this application may further include: If the same thread is detected to be holding the read-write lock at N consecutive detection moments, the interval time between two adjacent detection moments is reduced. N is greater than or equal to 2. By reducing the interval time between two adjacent detection moments, the blocking information of the thread can be obtained more timely to solve the system blocking problem, improve the efficiency of solving the blocking problem, and also better improve the user experience.

[0013] In a possible implementation, the method provided in this application may further include: Adding the identifier of the thread holding the read-write lock to the lock-holding list. Determining the holding time of the thread currently holding the read-write lock includes: determining the holding time of the thread indicated by each identifier in the lock-holding list. By configuring the lock-holding list to record the identifiers of the threads holding the read-write lock, the thread holding the lock can be quickly determined, improving the efficiency of the solution.

[0014] In a possible implementation, the method provided in this application may further include: If a thread successfully releases the read-write lock, deleting the identifier of the thread that releases the read-write lock from the lock-holding list.

[0015] In a possible implementation, the method provided by this application may further include: obtaining, through a probe point, the time point when a thread that calls a read-write lock applies for the read-write lock. After a third thread successfully obtains the read-write lock, if the time for the third thread to wait for the lock is greater than or equal to a second threshold, output the blocking information of a fourth thread. The time for waiting for the lock is the time point when the third thread successfully obtains the read-write lock minus the time point when the third thread applies for the read-write lock. During the process of the third thread waiting for the read-write lock, the fourth thread holds the read-write lock. Determining the lock-holding status of other threads based on the thread's lock-waiting time, and then obtaining the blocking information of other threads can obtain thread blocking information more efficiently and accurately.

[0016] In a possible implementation, outputting the blocking information of a first thread may specifically be implemented as: determining, according to the blocking information of the first thread, the cause of the block, where the cause of the block includes the resources used by the processes executed during the period when the first thread holds the lock and / or the hardware used by these processes; outputting the cause of the block. This is to facilitate the user to quickly locate and resolve the block.

[0017] In a possible implementation, outputting the cause of the block may specifically be implemented as: outputting the cause of the block through one or more of an operating system (OS), a baseboard management controller (BMC), and a basic input output system (BIOS).

[0018] In a second aspect, a device for obtaining thread read-write blocking information is provided. The device may include: an obtaining unit, a determining unit, and an output unit. Among them:

[0019] The obtaining unit is configured to obtain, through a probe point registered at the application interface of the read-write lock, the time point when a thread that calls the read-write lock successfully obtains the read-write lock.

[0020] The determining unit is configured to determine the lock-holding time of the thread that currently holds the read-write lock.

[0021] The output unit is configured to, if the lock-holding time of a first thread is greater than or equal to a first threshold, output the blocking information of the first thread; the first thread is any thread that currently holds the read-write lock.

[0022] Through the solution provided by this application, a probe point is registered at the application interface of the read-write lock. Through this probe point, the time point when a thread successfully obtains the read-write lock can be automatically obtained, and then the lock-holding time of the thread can be accurately obtained. When the lock is held for too long, the blocking information of the thread is automatically output. The entire process is automatically implemented, and basically no secondary processing of the log is required, reducing the amount of output log and greatly improving the efficiency of obtaining thread blocking information.

[0023] Furthermore, in the solution provided by the embodiments of the present application, the whole process is automatically implemented. Users do not need to perceive a large number of interface files, nor do they need to understand the implementation mechanism of the system, which greatly reduces the professional technical requirements for users.

[0024] In a possible implementation manner, the above-mentioned obtaining unit is specifically configured to: detect the instruction information of the application interface through the detection point; when at the first time point, the detection point detects the first instruction information, use the first time point as the time point when the second thread successfully obtains the read-write lock. The first instruction information is used to allocate the read-write lock to the second thread.

[0025] In a possible implementation manner, the above-mentioned determining unit is specifically configured to: at the detection moment, determine the holding time of the thread currently holding the read-write lock at the detection moment. The holding time of a thread is the detection moment minus the time point when the thread successfully obtains the read-write lock. Configure the detection moment according to the actual scenario to obtain the blocking information of the thread as required.

[0026] In a possible implementation manner, multiple detection moments are set periodically. By detecting periodically, the blocking information of the thread can be obtained in a timely manner to solve the system blocking problem.

[0027] In a possible implementation manner, the device may further include a control unit, configured to reduce the interval time between two adjacent detection moments if the same thread is detected to hold the read-write lock at N consecutive detection moments. N is greater than or equal to 2. By reducing the interval time between two adjacent detection moments, the blocking information of the thread can be obtained more timely to solve the system blocking problem, improve the efficiency of solving the blocking problem, and also better improve the user experience.

[0028] In a possible implementation manner, the device may further include a configuration unit, configured to add the identifier of the thread holding the read-write lock to the lock-holding list. Correspondingly, the determining unit is specifically configured to: determine the holding time of the thread indicated by each identifier in the lock-holding list. By configuring the lock-holding list to record the identifiers of the threads holding the read-write lock, the threads holding the lock can be quickly determined, improving the efficiency of the solution.

[0029] In a possible implementation manner, the above-mentioned configuration unit may further be configured to: if the thread successfully releases the read-write lock, delete the identifier of the thread that releases the read-write lock from the lock-holding list.

[0030] In a possible implementation, the above-mentioned obtaining unit can also be used to: obtain, through a detection point, the time point when a thread that calls a read-write lock applies for the read-write lock. The output unit is specifically configured to: after a third thread successfully obtains the read-write lock, if the time for the third thread to wait for the lock is greater than or equal to a second threshold, output the blocking information of a fourth thread. The time for waiting for the lock is the time point when the third thread successfully obtains the read-write lock minus the time point when the third thread applies for the read-write lock. During the process of the third thread waiting for the read-write lock, the fourth thread holds the read-write lock. Determining the lock-holding status of other threads through the thread's lock-waiting time, and then obtaining the blocking information of other threads, can obtain thread blocking information more efficiently and accurately.

[0031] In a possible implementation, the output unit is specifically configured to: determine, according to the blocking information of a first thread, the blocking reason, where the blocking reason includes the resources used by the processes executed during the period when the first thread holds the lock and / or the hardware used by these processes; output the blocking reason. So as to facilitate the user to quickly locate and solve the blockage.

[0032] In a possible implementation, the output unit is specifically configured to: output the blocking reason through one or more of the OS, BMC, and BIOS.

[0033] It should be noted that the device for obtaining thread read-write blocking information provided in the second aspect is used to implement the method for obtaining thread read-write blocking information provided in the first aspect above. Its specific implementation can refer to the specific implementation of the first aspect above, and will not be elaborated here.

[0034] In a third aspect, the present application provides a computing device, which can implement the functions in the method examples described in the first aspect above. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The computing device can exist in the form of a chip product.

[0035] In a possible implementation, the computing device may include a processor and a transmission interface. Among them, the transmission interface is used to receive and send data. The processor is configured to call program instructions stored in a memory so that the computing device executes the functions in the method examples described in the first aspect above.

[0036] In a fourth aspect, a computer-readable storage medium is provided, including instructions, which when running on a computer, cause the computer to execute the method for obtaining thread read-write blocking information described in any of the above aspects or any possible implementation.

[0037] In a fifth aspect, a computer program product is provided, which when running on a computer, causes the computer to execute the method for obtaining thread read-write blocking information described in any of the above aspects or any possible implementation.

[0038] In a sixth aspect, a chip system is provided. The chip system includes a processor and may further include a memory for implementing the functions in the above method. The chip system may be composed of chips or may include chips and other discrete devices.

[0039] The solutions provided in the above third aspect to sixth aspect are used to implement the method provided in the first aspect, and thus can achieve the same beneficial effects as the first aspect, which will not be elaborated here.

[0040] It should be noted that, on the premise that the solutions do not conflict, any possible implementation manners in the above aspects can be combined. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 FIG. is a schematic diagram of an application scenario of a read-write lock;

[0042] Figure 2 FIG. is a schematic diagram of an observation and positioning scenario;

[0043] Figure 3 FIG. is a schematic diagram of a resource management scenario provided by an embodiment of the present application;

[0044] Figure 4 FIG. is a schematic diagram of the structure of a computing device provided by an embodiment of the present application;

[0045] Figure 5 FIG. is a schematic diagram of a process for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0046] Figure 6 FIG. is a schematic diagram of a scenario for configuring a lock-holding list of a read-write lock provided by an embodiment of the present application;

[0047] Figure 7 FIG. is another schematic diagram of a process for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0048] Figure 8 FIG. is still another schematic diagram of a process for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0049] Figure 9 FIG. is a schematic diagram of a scenario for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0050] Figure 10 FIG. is a schematic diagram of the structure of a device for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0051] Figure 11 FIG. is another schematic diagram of the structure of a device for obtaining thread read-write blocking information provided by an embodiment of the present application;

[0052] Figure 12 This is a schematic structural diagram of another computing device provided by an embodiment of the present application. Detailed implementation manners

[0053] Terms such as "first", "second", and "third" in the description of the present application, the claims, and the above-mentioned drawings are used to distinguish different objects, rather than to limit a specific order.

[0054] In the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner for easy understanding.

[0055] In the description of the present application, unless otherwise specified, " / " means that the objects associated before and after are in an "or" relationship. For example, A / B may represent A or B; "and / or" in the present application is merely a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. And, in the description of the present application, unless otherwise specified, "a plurality of" means two or more than two. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of a single item (item) or plural items (items). For example, at least one (item) of a, b, or c may represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, and c can be single or multiple.

[0056] In the embodiments of the present application, at least one can also be described as one or more. A plurality can be two, three, four, or more, and the present application does not make a limitation.

[0057] Before describing the embodiments of the present application, the nouns involved in the embodiments of the present application will be explained first.

[0058] A read-write lock is a special spin lock that divides visitors to shared resources into readers and writers. Readers only perform read access to shared resources, while writers need to perform write operations on shared resources. Only one thread can hold the read-write lock in write mode at a time, but multiple threads can hold the read-write lock in read mode simultaneously. When the read-write lock is in the write-locked state, all threads attempting to lock this lock will be blocked until the lock is unlocked. When the read-write lock is in the read-locked state, all threads attempting to lock it in read mode can obtain access rights, but if a thread wishes to lock this lock in write mode, it must wait until all threads release the lock. Generally, when the read-write lock is in the read-mode locked state, if another thread attempts to lock it in write mode, the read-write lock usually blocks subsequent read-mode lock requests, which can avoid long-term occupation of the read-mode lock and long-term blocking of waiting write-mode lock requests.

[0059] The application interface of the read-write lock refers to the communication rules used to apply for the read-write lock in the computer function layer.

[0060] The release interface of the read-write lock refers to the communication rules used to release the read-write lock in the computer function layer.

[0061] Blocking information refers to the information used to indicate the behavior of a thread during the period of holding a lock.

[0062] Figure 1 Schematically shows an application scenario of a read-write lock. As Figure 1 shown, both the readers and writers applying for the read-write lock are in the waiting-for-lock state. In the lock-holding state, multiple readers can access the shared resource concurrently, or a single writer can access the shared resource alone.

[0063] As mentioned above, in the application of the read-write lock, it is necessary to observe the process of the read-write lock and locate and determine the cause of blocking. Figure 2 Schematically shows an observation and location scenario. As shown in Figure 2, tools using the debugfs and tracefs technologies can be used to observe and locate the process of the read-write lock to locate and determine the cause of blocking.

[0064] However, this solution has a complex configuration, numerous interfaces, and requires users to be very familiar with the use of the tools. It requires secondary processing of information, further increasing the professional technical requirements for users. After the detection object changes, it does not support automatic recognition and update, and requires reconfiguration, resulting in low usability and efficiency of the solution. Secondly, the filtering mechanism is too simple, and the logs can only be output in chronological order, with the possibility of losing logs, resulting in low accuracy of the solution.

[0065] Based on this, the present application provides a method for obtaining thread read / write blocking information. By means of the probe points registered in the acquisition interface of the read-write lock, the moment when the thread acquires the lock is recorded, and the threads with a lock-holding time greater than the threshold are regarded as abnormal threads, and the blocking information of the abnormal threads is automatically output. In this way, the whole process is automatically implemented, basically no secondary processing of the logs is required, and the amount of logs output is also reduced, greatly improving the efficiency of obtaining thread blocking information.

[0066] The implementation manners of the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0067] The solution provided by the present application can be applied to Figure 3 The schematic diagram of the resource management scenario shown in the figure. Figure 3 In the resource management scenario shown in the figure, it includes a client 310, a computing device 320, and a network 330. The client 310 communicates with the computing device 320 through the network 330 to access the data in the computing device 320.

[0068] Among them, the network 330 may refer to the Internet or others, which is not limited in the embodiments of the present application.

[0069] In some embodiments, a server client program 311 may be installed in the client 310. The client 310 runs the server client program 311 to display a user interface (UI), and the user 340 operates the UI to access the computing device 320. The client 310 refers to a computer connected to the network 330, and can also be called a workstation. Different clients can share resources on the network (such as computing resources, storage resources).

[0070] A shared memory 3201 is deployed in the computing device 320 as the shared data for storing processes. The operating system 3203 of the computing device 320, as a kernel-level manager, manages the data stored in the shared memory 3201 by deploying a read-write lock 3202. The access of the client 310 to the shared memory 3201 includes read operations and write operations.

[0071] A processor 3204 is deployed in the computing device 320, which is used to execute the solution of the present application. Through the operating system 3203, it observes and locates abnormal threads in the process of the read-write lock 3202 managing the shared memory 3201, and outputs the blocking information of the abnormal threads to the client 310, indicating the behavior of the abnormal threads during the lock-holding period, so that the user 340 can handle the block.

[0072] The computing device 320 can be a server.

[0073] It should be noted that the above Figure 3The schematic resource management scenario is only an example of the application scenario of the solution of this application, and does not limit the application scenario of the solution of this application.

[0074] Next, in combination with the accompanying drawings, the solution provided by the embodiments of this application will be specifically described.

[0075] On the one hand, an embodiment of this application provides a computing device 40 for executing the method for obtaining thread read-write blocking information provided by this application. For example, the computing device 40 may be Figure 3 the computing device 320 shown in the figure.

[0076] Figure 4 The figure shows the structural diagram of the computing device 40 provided by the embodiment of this application. As Figure 4 shown, the computing device 40 may include a processor 401, a memory 402, and a transceiver 403.

[0077] Next, in combination with Figure 4 the following, each component of the processing device 40 will be specifically introduced:

[0078] The memory 402 may be a volatile memory, such as a random-access memory (RAM); or a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or a combination of the above types of memories, for storing application program codes, configuration files, data information, or other content that can implement the method of this application. In other possible cases, the memory 402 may also be deployed in other devices independent of the computing device 40.

[0079] The transceiver 403 is used for information interaction between the computing device 40 and other devices.

[0080] The processor 401 may be the control center of the computing device 40. For example, the processor 401 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs).

[0081] Exemplarily, by running or executing software programs and / or modules stored in the memory 402, the processor 401 may perform the following functions:

[0082] Obtain the time point when the thread that calls the read-write lock successfully obtains the read-write lock through the probe point registered at the application interface of the read-write lock; determine the holding time of the thread currently holding the read-write lock; if the holding time of the first thread is greater than or equal to the first threshold, output the blocking information of the first thread; the first thread is any thread currently holding the read-write lock.

[0083] On the other hand, the present application provides a method for obtaining read-write blocking information. The method for obtaining thread read-write lock blocking information provided by the present application can be applied to obtain the blocking information of abnormal threads in the read-write lock. The process of obtaining the blocking information of abnormal threads in different read-write locks is the same. The embodiments of the present application only describe the process of obtaining the blocking information of abnormal threads in one read-write lock below.

[0084] A thread in a read-write lock refers to a thread in a process that accesses the shared resources managed by the read-write lock. The threads observed in the solution of the present application may be threads in the process to be observed. The process to be observed may be a process for which the expected observation is input in advance, or a process selected by a preset rule, or a process determined by other methods. The embodiments of the present application do not limit this. The threads described in the following embodiments all belong to the process to be observed.

[0085] It should be noted that each step described in the embodiments of the present application may be executed by the processor 401 in the computing device 40.

[0086] As Figure 5 shown, the method provided by the present application may include:

[0087] S501. The processor obtains the time point when the thread that calls the read-write lock successfully obtains the read-write lock through the probe point registered at the application interface of the read-write lock.

[0088] Among them, the detection points configured in the application interface can parse the signaling passing through the application interface, and determine the function of the instruction passing through according to the parsed content. When it is parsed that a certain instruction is the instruction information for allocating the read-write lock to a certain thread, the time point when the instruction information is obtained is the time point when the thread successfully obtains the read-write lock.

[0089] Exemplarily, S501 can be specifically implemented as: detecting the instruction information of the application interface through the detection point; when at the first time point, the detection point detects the first instruction information, taking the first time point as the time point when the second thread successfully obtains the read-write lock. Among them, the first instruction information is used to allocate the read-write lock to the second thread. The second thread is any thread that applies for the read-write lock.

[0090] Of course, due to the different specific implementations of the read-write lock function, the method for obtaining the time point when the thread successfully obtains the lock can be different, and the embodiments of the present application do not make specific limitations on this.

[0091] Exemplarily, the application and release interfaces of the read lock can be: down_read interface, down_read_killable interface, down_read_trylock interface, up_read interface.

[0092] Exemplarily, the application and release interfaces of the write lock can be: down_write interface, down_write_killable interface, down_write_trylock interface, up_write interface.

[0093] S502. The processor determines the holding time of the thread currently holding the read-write lock.

[0094] In a possible implementation manner, S502 can be executed after a certain thread applies for and obtains the read-write lock.

[0095] Exemplarily, through the above detection point, it can be detected that the instruction information for applying for the read-write lock has passed on the application interface of the read-write lock, then it is determined that a thread applies for and obtains the read-write lock, and then S502 is executed.

[0096] In another possible implementation manner, S502 can be executed at the detection moment.

[0097] Of course, the timing of executing S502 can be configured according to actual needs, and the embodiments of the present application do not limit this.

[0098] Specifically, the "thread currently holding the read-write lock" described in S502 is the thread holding the read-write lock when S502 is executed.

[0099] Among them, the current lock-holding time of a thread is the time point when S502 is executed minus the time point when the thread successfully acquires the read-write lock.

[0100] Exemplarily, if S502 is executed at the detection time point, the current lock-holding time of a thread is the detection time point minus the time point when the thread successfully acquires the read-write lock.

[0101] The time point when the thread successfully acquires the read-write lock has been obtained in S501.

[0102] Specifically, the detection time point can be a pre-configured time point for detecting the blocking information of an abnormal thread acquiring an abnormal thread. In practical applications, the detection time point can be configured according to actual needs, and the present application embodiment places no restrictions on the configuration content and method of the detection time point.

[0103] In a possible implementation manner, multiple detection time points are set periodically. For the periodic interval of the detection time points, it can be configured according to actual needs.

[0104] Exemplarily, in practical applications, according to the characteristics of the scenario, the lock application blocking time is different in different scenarios, and the period of the detection time point can be set based on the actual blocking time.

[0105] In a possible implementation manner, the period value of the detection time point can be input by the user.

[0106] In another possible implementation manner, the user can pre-configure the period values corresponding to different reference information, and the period value of the detection time point can be determined by the device executing the present application according to the real-time reference information for the real-time reference information corresponding period value. Among them, the reference information can be the identifier of the process to be observed, the identifier of the read-write lock, the service scenario, or others.

[0107] Furthermore, if the same thread is detected to hold the read-write lock at N consecutive detection time points, the interval time between two adjacent detection time points is reduced. N is greater than or equal to 2. By reducing the interval time between two adjacent detection time points, the blocking information of the thread can be obtained more timely to solve the system blocking problem, improve the efficiency of solving the blocking problem, and also better improve the user experience.

[0108] In a possible implementation manner, to reduce the interval time between two adjacent detection time points, the interval time between two adjacent detection time points can be reduced once or multiple times according to a preset fixed step size.

[0109] In another possible implementation manner, reducing the interval time between two adjacent detection time points can be specifically implemented as: determining a reduction value according to N, and reducing the current interval time between two adjacent detection time points by this reduction value.

[0110] Of course, a specific implementation solution for reducing the interval time between two adjacent detection times can also be configured according to actual requirements, which is not limited in the embodiments of the present application.

[0111] Specifically, for a thread holding a read-write lock, it can be recorded so as to determine which threads are the threads holding the lock when executing S502.

[0112] Exemplarily, a lock-holding list of the read-write lock can be configured, and the identifier of the thread holding the read-write lock is added to the lock-holding list.

[0113] In a possible implementation manner, the identifier of the thread can be added to the lock-holding list at the moment when the thread successfully acquires the read-write lock.

[0114] Correspondingly, when executing S502, determining the lock-holding time of the thread currently holding the read-write lock can be specifically implemented as: determining the lock-holding time of the thread indicated by each identifier in the lock-holding list.

[0115] It should be understood that the lock-holding list of the read-write lock includes the identifiers of the threads currently holding the read-write lock, and the thread identifiers in the lock-holding list can be one or more.

[0116] Exemplarily, when a thread holds the read lock of the read-write lock, due to the concurrent feature of the read lock, there can be multiple threads holding the lock, and the thread identifiers in the lock-holding list of the read-write lock can be multiple. When a thread holds the write lock of the read-write lock, due to the non-concurrent feature of the write lock, there can be only one thread holding the lock, and the thread identifier in the lock-holding list of the read-write lock is one.

[0117] Furthermore, the embodiments provided in the present application can further include: if a thread successfully releases the read-write lock, the identifier of the thread that releases the read-write lock is deleted from the lock-holding list.

[0118] Exemplarily, at the moment when a thread successfully releases the read-write lock, the identifier of the thread is deleted from the lock-holding list.

[0119] Exemplarily, Figure 6 illustrates a lock-holding list configuration scenario of a read-write lock. As Figure 6 shown, at time T2, an event occurs: thread A successfully acquires the read-write lock, and thread A is added to the lock-holding list at time T2. At time T5, an event occurs: thread B successfully acquires the read-write lock, and thread B is added to the lock-holding list at time T2. At time T6, an event occurs: thread B successfully releases the read-write lock, and thread B is deleted from the lock-holding list at time T6. At the detection time T7, only thread A exists in the lock-holding list, then thread A is the suspected object at time T7, and its lock-holding time is obtained as (T7 - T2) in S502.

[0120] After S502, S503 is executed.

[0121] S503. If the lock-holding time of the first thread is greater than or equal to the first threshold, the processor outputs the blocking information of the first thread.

[0122] Herein, the first thread is any thread currently holding the read-write lock. For example, the first thread is any thread that holds the lock when executing S502, and the first thread can be one or more.

[0123] Specifically, the blocking information of the first thread is used to indicate the behavior of the first thread during the lock-holding period.

[0124] Exemplarily, the blocking information of the first thread can be stack information.

[0125] In a possible implementation, the behavior of the first thread during the lock-holding period can be the operations of the first thread during the lock-holding period and the corresponding processes of these operations.

[0126] Exemplarily, outputting the blocking information of the first thread can be printing the stack information of the first thread to the system log file.

[0127] Herein, the value of the first threshold can be configured according to actual requirements. The first threshold can be a threshold value for determining whether it is an abnormal lock-holding time, and in different scenarios, the value of the first threshold can be different.

[0128] Exemplarily, different first thresholds can be configured for different processes. In S502, the current lock-holding time of the thread can be compared with the first threshold corresponding to the process to which the thread belongs.

[0129] Of course, different first thresholds can also be configured for different service scenarios. When executing S502, just select the corresponding first threshold for comparison, which will not be elaborated here one by one.

[0130] If, after the current execution of S502, the lock-holding times of all the threads currently holding the read-write lock are less than the first threshold, the process ends.

[0131] Through the solution provided by this application, a probe point is registered at the application interface of the read-write lock. Through this probe point, the time point when the thread successfully acquires the read-write lock can be automatically obtained, and then the lock-holding time of the thread can be accurately obtained. When the lock is held for too long, the blocking information of the thread is automatically output. The whole process is automatically implemented, basically without secondary processing of the logs, and the amount of output logs is also reduced, greatly improving the efficiency of obtaining the blocking information of the thread.

[0132] Furthermore, in the solution provided by the embodiments of this application, the whole process is automatically implemented. Users do not need to perceive a large number of interface files, nor do they need to understand the implementation mechanism of the system, greatly reducing the professional technical requirements for users.

[0133] Further, the method for obtaining thread read / write blocking information provided in this application can also output the blocking information of the thread holding the lock when the lock waiting time is too long. For example Figure 7 As shown, the solution provided in this application can also include S504 and S505.

[0134] S504. The processor obtains the time point when the thread calling the read / write lock applies for the read / write lock through the probe point.

[0135] In a possible implementation, the probe point registered for the application interface of the above read / write lock can also be used to obtain the time point when the thread applies for the read / write lock. In S504, the time point when the thread calling the read / write lock applies for the read / write lock is obtained through the probe point registered for the application interface of the read / write lock.

[0136] Among them, the probe point configured in the application interface can parse the signaling passing through the application interface, and determine the function of the instruction passing through according to the parsed content. When it is parsed that a certain instruction is the instruction information for a certain thread to apply for the read / write lock, the time point of obtaining the instruction information is the time point when the thread applies for the read / write lock.

[0137] Exemplarily, S504 can be specifically implemented as: detecting the instruction information of the application interface through the above probe point; when at the second time point, the probe point detects the second instruction information, taking the second time point as the time point when the fifth thread successfully obtains the read / write lock. Among them, the second instruction information is the instruction information for the fifth thread to apply for the read / write lock.

[0138] Among them, the fifth thread is any thread in the process accessing the shared resource managed by the read / write lock.

[0139] S505. After the third thread successfully obtains the read / write lock, if the time for the third thread to wait for the lock is greater than or equal to the second threshold, the processor outputs the blocking information of the fourth thread.

[0140] Among them, the time for waiting for the lock is the time point when the third thread successfully obtains the read / write lock minus the time point when the third thread applies for the read / write lock. The fourth thread holds the read / write lock during the process of the third thread waiting for the read / write lock.

[0141] Among them, the third thread and the fourth thread are any threads in the process accessing the shared resource managed by the read / write lock.

[0142] In a possible implementation, the fourth thread can be the thread that holds the read / write lock during the process of the third thread waiting for the lock.

[0143] In another possible implementation, the fourth thread can include the threads that hold the read / write lock and whose lock holding time is greater than or equal to the first threshold during the process of the third thread waiting for the lock.

[0144] Among them, the value of the second threshold can be configured according to actual needs. The second threshold can be a threshold value for determining whether it is an abnormal waiting lock time, and in different scenarios, the value of the second threshold can be different.

[0145] Exemplarily, different second thresholds can be configured for different processes. In S505, the waiting lock time of the thread can be compared with the second threshold corresponding to the process to which the thread belongs.

[0146] Of course, different second thresholds can also be configured for different service scenarios. When executing S505, just select the corresponding second threshold for comparison, and details are not elaborated here one by one.

[0147] Furthermore, a detection point can also be registered at the release interface of the read-write lock, and this detection point is used to obtain the time point when the thread releases the read-write lock. The time point when a thread releases the lock minus the time point when it successfully acquires the lock is the total time the thread holds the lock, which can indicate the total time the lock-holding thread holds the lock. The "lock-holding time" described in the foregoing embodiments is only the situation of one observation period. It is possible that the thread holds the lock for a long time, and the thread will be detected as holding the lock in multiple rounds of observations; that is, the blocking information of the thread will be output in each round of observations.

[0148] Furthermore, as Figure 7 shown, S503 in the method for obtaining thread read-write blocking information provided by the embodiments of the present application can specifically be implemented as S5031 and S5032.

[0149] S5031. The processor determines the blocking reason according to the blocking information of the first thread.

[0150] Among them, the blocking reason includes the resources used by the process executed during the period when the first thread holds the lock and / or the hardware used by the process.

[0151] Specifically, the blocking information of the first thread indicates the behavior and the executed process during the period when the first thread holds the read-write lock. According to the configured policy, the blocking reason corresponding to the blocking information of the first thread in the policy is determined, which is the blocking reason determined in S5031.

[0152] Among them, the blocking reasons corresponding to different blocking information in the policy can be configured according to actual experience, and the embodiments of the present application do not limit the specific content of the policy.

[0153] S5032. The processor outputs the blocking reason.

[0154] Exemplarily, in S5032, the blocking reason can be output through the OS, or the BMC, or the BIOS, so that the user can solve the block according to the blocking reason.

[0155] Of course, the reason for the block can also be output through other interaction methods with the user, and the embodiments of the present application do not limit this.

[0156] Figure 8 Schematically shows the process of obtaining thread read / write block information provided by the present application. As Figure 8 shown, the time direction is from left to right. The computing device first receives the process to be observed and the observation period input by the user. The computing device traverses the system process list to detect whether there is a process applying for access to the shared resource.

[0157] At time T1, the computing device detects that Thread 1 applies for obtaining a read / write lock to access the shared resource, and records time T1.

[0158] At time T2, the computing device detects that Thread 1 successfully obtains the read / write lock, records time T2. Thread 1 is added to the lock-holding list of this read / write lock. It is judged whether the lock-waiting time of Thread 1 (T2 - T1) is greater than or equal to the second threshold. If (T2 - T1) is greater than or equal to the second threshold, the block information of the process holding this read / write lock during T1 to T2 is output. If (T2 - T1) is less than the second threshold, it means that the lock-waiting time of Thread 1 is normal and no information needs to be output.

[0159] Time T3 is the detection time corresponding to the observation period. At time T3, the computing device judges whether the lock-holding list is not empty. If it is not empty, it is judged whether the lock-holding time of Thread 1 in the current lock-holding list (T3 - T2) is greater than or equal to the first threshold. If (T3 - T2) is greater than or equal to the first threshold, the block information of Thread 1 is output. If (T3 - T2) is less than the first threshold, it means that the lock-holding time of Thread 1 is normal and no information needs to be output.

[0160] At time T4, the computing device detects that Thread 1 successfully releases the read / write lock, records time T4, and deletes Thread 1 from the lock-holding list of this read / write lock.

[0161] The following describes the solution provided by the present application in detail through specific examples.

[0162] Figure 9 Schematically shows the scenario of obtaining thread read / write block information provided by the present application. The time direction is from left to right. Thread 1 applies for a read lock at time T1, obtains the read lock at time T2 (adds Thread 1 to the lock-holding list), and releases the read lock at time T3 (deletes Thread 1 from the lock-holding list). During the period when Thread 1 holds the read lock (T3 - T2), Thread 2 applies for a write lock and fails at time T4, and waits until time T5 after T3 before Thread 2 obtains the write lock (adds Thread 2 to the lock-holding list), and releases the write lock at time T6 (deletes Thread 2 from the lock-holding list).

[0163] At detection time T7, the current lock-holding time of thread 1 in the lock-holding list, T7 - T2, is greater than the first threshold, and the blocking information of thread 1 is printed.

[0164] If the lock-waiting time of thread 2 (T5 - T4) is greater than or equal to the second threshold, it means that thread 2 has waited for the lock for too long. Thread 2 is the victim in this case. The solution of the present application can automatically output the blocking information of thread 1, indicating the behavior of thread 1 during the lock-holding period, that is, printing the call stack information to the system log file at the object management level.

[0165] In a typical scenario, assume that after thread 1 holds the lock and enters the disk I / O read / write process, the data to be accessed happens to be stored at a position with bad sectors on the medium, triggering multiple hardware read / write retries before successfully obtaining the data. Therefore, for the lock-holding thread 1, it perceives that the file read / write takes a long time, while for thread 2 (or other threads), it perceives that obtaining the lock is blocked. For this scenario, the solution of the present application will automatically output the information about the slow disk I / O read / write process and thread 1.

[0166] Exemplarily, assume that the solution of the present application provides relevant functions in a ko file, and assume the file name is debug.ko. The content input by the user can be: insmod debug.ko comm="proc1","proc2","proc3" uid=uid1,uid2,uid3 dims=500.

[0167] The parameters are described as follows:

[0168] comm: A list of process names, enabling cross-process monitoring, that is, monitoring multiple locks simultaneously.

[0169] uid: A list of uids corresponding to the processes.

[0170] dims: The dump interval in milliseconds, the observation period.

[0171] At a detection time, the output information can be as follows:

[0172] [238908.764881][dbg]{1}warning![5671:kworker / 3:0:5671]rsem holdercost 2047ms

[0173] [238908.764881][dbg]{1}Call trace:

[0174] [238908.764892][dbg]{1}msleep+0x2a / 0x40

[0175] [238908.764894][dbg]{1}delay_rwsem_unlock+0xa9 / 0xd1[irb]

[0176] [238908.764897][dbg]{1}process_one_work+0x171 / 0x390

[0177] [238908.764898][dbg]{1}worker_thread+0x49 / 0x3f0

[0178] [238908.764899][dbg]{1}kthread+0xf8 / 0x130

[0179] [238908.764902][dbg]{1}ret_from_fork+0x35 / 0x40

[0180] [238908.764903][dbg]{1}0xffffffffffffffff

[0181] [238908.764904][dbg]dump 1task

[0182] Here is an exception constructed by simulation. It can be seen that the exception occurred in the function delay_rwsem_unlock, which called the msleep function, resulting in the lock release being blocked. The exception was caused by the irb driver. The functions that caused the exception were intuitively outputted.

[0183] The above mainly introduced the solution provided by the embodiment of the present invention from the perspective of the working principle of the device. It can be understood that in order to implement the above functions, the device includes the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should easily realize that the present invention can be implemented in the form of hardware or a combination of hardware and computer software by combining the units and algorithm steps of each example described in the embodiments disclosed herein. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0184] The embodiments of the present application may divide the apparatus for obtaining thread read-write blocking information provided by the present application into functional modules according to the above method examples. For example, each functional module may be corresponding to each function, or two or more functions may be integrated into one processing module. The above integrated module may be implemented in the form of hardware or in the form of a software functional module. The division of modules in the embodiments of the present application is illustrative, only a logical function division, and there may be other division methods in actual implementation.

[0185] In the case of dividing each functional module corresponding to each function, Figure 10 FIG. shows a possible structural schematic diagram of the apparatus for obtaining thread read-write blocking information involved in the above embodiments. The apparatus 100 for obtaining thread read-write blocking information may be a functional module or a chip. As Figure 10 shown, the apparatus for obtaining thread read-write blocking information may include: an obtaining unit 1001, a determining unit 1002, and an output unit 1003. Among them, the obtaining unit 1001 is used to execute Figure 5 or Figure 7 the process S501 in, or execute Figure 7 the process S504 in; the determining unit 1002 is used to execute Figure 5 or Figure 5 the process S502 in; the output unit 1003 is used to execute Figure 5 or Figure 7 the process S503 in, or execute Figure 7 the process S505 in. Among them, all relevant contents of each step involved in the above method embodiments can be cited in the function descriptions of the corresponding functional modules, and will not be elaborated here.

[0186] In a possible implementation manner, the above obtaining unit 1001 may specifically be used to: detect the instruction information of the application interface through the detection point; when at a first time point, the detection point detects the first instruction information, use the first time point as the time point when the second thread successfully obtains the read-write lock. Among them, the first instruction information is used to allocate the read-write lock to the second thread.

[0187] In a possible implementation manner, the above determining unit 1002 may specifically be used to: at the detection moment, determine the lock-holding time of the thread currently holding the read-write lock at the detection moment, and the lock-holding time of a thread is the detection moment minus the time point when the thread successfully obtains the read-write lock.

[0188] In a possible implementation manner, multiple detection moments are set periodically.

[0189] In a possible implementation manner, as Figure 11As shown, the apparatus 100 for obtaining thread read-write blocking information may further include a control unit 1004, configured to reduce the interval time between two adjacent detection times if the same thread is detected to hold the read-write lock at N consecutive detection times. N is greater than or equal to 2.

[0190] In a possible implementation, as Figure 11 shown, the apparatus 100 for obtaining thread read-write blocking information may further include a configuration unit 1005, configured to add the identifier of the thread holding the read-write lock to the lock-holding list. Correspondingly, the determining unit 1002 is specifically configured to: determine the lock-holding time of the thread indicated by each identifier in the lock-holding list.

[0191] In a possible implementation, the above configuration unit 1005 may further be configured to: if the thread successfully releases the read-write lock, delete the identifier of the thread that releases the read-write lock from the lock-holding list.

[0192] In a possible implementation, the above obtaining unit 1001 may further be configured to: obtain, through a probe point, the time point when the thread that calls the read-write lock applies for the read-write lock. Correspondingly, the output unit 1003 may specifically be configured to: after a third thread successfully obtains the read-write lock, if the waiting time of the third thread for the lock is greater than or equal to a second threshold, output the blocking information of a fourth thread. The waiting time for the lock is the time point when the third thread successfully obtains the read-write lock minus the time point when the third thread applies for the read-write lock. The fourth thread holds the read-write lock during the process of the third thread waiting for the read-write lock.

[0193] In a possible implementation, the output unit 1003 is specifically configured to: determine a blocking reason according to the blocking information of a first thread, where the blocking reason includes resources used by the processes executed during the lock-holding period of the first thread and / or the hardware used by these processes; and output the blocking reason.

[0194] In a possible implementation, the output unit 1003 is specifically configured to: output the blocking reason through one or more of an OS, a BMC, and a BIOS.

[0195] In the case of adopting an integrated unit, Figure 12 shows a possible structural schematic diagram of the computing device involved in the above embodiment. The computing device 120 may include: a processing module 1201 and a communication module 1202. The processing module 1201 is configured to control and manage the actions of the computing device 120, and the communication module 1202 is configured to communicate with other devices. For example, the processing module 1201 is configured to execute Figure 5 or Figure 8 any one of the processes S501 to S503. The computing device 120 may further include a storage module 1203, configured to store the program code and data of the computing device 120.

[0196] Among them, the processing module 1201 may be Figure 4 the processor 401 in the physical structure of the computing device 40 shown. It can be a processor or a controller. For example, it can be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in connection with the disclosure of this application. The processing module 1201 can also be a combination that realizes computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication module 1202 may be Figure 4 the transceiver 403 in the physical structure of the computing device 40 shown. The communication module 1202 can be a communication port, or it can be a transceiver, a transceiver circuit, or a communication interface, etc. Alternatively, the above communication interface can communicate with other devices through the above elements having transceiver functions. The above elements having transceiver functions can be implemented by an antenna and / or a radio frequency device. The storage module 1203 can be Figure 4 the memory 402 in the physical structure of the computing device 40 shown.

[0197] As described above, the device 100 or the computing device 120 for obtaining thread read-write blocking information provided in the embodiments of the present application can be used to implement the corresponding functions in the methods implemented in the above embodiments of the present application. For the sake of convenience of description, only the parts related to the embodiments of the present application are shown. For the specific technical details not disclosed, please refer to the embodiments of the present application.

[0198] As another form of this embodiment, a computer-readable storage medium is provided, on which instructions are stored, and when the instructions are executed, the method for obtaining read-write blocking information in the above method embodiments is executed.

[0199] As another form of this embodiment, a computer program product containing instructions is provided. When the computer program product runs on a computer, the computer is caused to execute the method for obtaining read-write blocking information in the above method embodiments when executed.

[0200] The embodiments of the present application further provide a chip system, which includes a processor for implementing the technical method of the embodiments of the present invention. In a possible design, the chip system further includes a memory for storing the necessary program instructions and / or data of the embodiments of the present invention. In a possible design, the chip system further includes a memory for the processor to call the application program code stored in the memory. The chip system can be composed of one or more chips, or can include chips and other discrete devices. The embodiments of the present application do not make specific limitations on this.

[0201] From the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0202] In several embodiments provided in the present application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0203] The units described as separate components may or may not be physically separated. The components displayed as units can be one physical unit or multiple physical units, that is, they can be located in one place or distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0204] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0205] If the above integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in the various embodiments of the present application. The foregoing storage medium includes: USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other various media that can store program codes.

[0206] As described above, it is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claimed rights.

Claims

1. A method for obtaining thread read / write blocking information, characterized in that The method includes: Detecting instruction information of the application interface through a probe point registered at the application interface of the read-write lock; When at a first time point, the probe point detects first instruction information, using the first time point as the time point when a second thread successfully acquires the read-write lock; wherein, the first instruction information is used to allocate the read-write lock to the second thread; At a detection moment, determining the lock-holding time of the thread currently holding the read-write lock at the detection moment, where the lock-holding time of a thread is the detection moment minus the time point when the thread successfully acquires the read-write lock; If the lock-holding time of a first thread is greater than or equal to a first threshold, outputting blocking information of the first thread; the first thread is any thread currently holding the read-write lock; if the same thread is detected to be holding the read-write lock at N consecutive detection moments, reducing the interval time between two adjacent detection moments; N is greater than or equal to 2; The reducing the interval time between two adjacent detection moments includes: determining a reduction value according to N, and reducing the interval time between the current two adjacent detection moments by the reduction value.

2. The method according to claim 1, characterized in that, A plurality of detection moments are set periodically.

3. The method according to claim 1, wherein The method further includes: adding an identifier of the thread holding the read-write lock to a lock-holding list; Determining the lock-holding time of the thread currently holding the read-write lock includes: determining the lock-holding time of each thread indicated by the identifier in the lock-holding list.

4. The method according to claim 3, wherein The method further includes: If a thread successfully releases the read-write lock, deleting the identifier of the thread that releases the read-write lock from the lock-holding list.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Through the probe point, obtaining the time point when a thread that calls the read-write lock applies for the read-write lock; After a third thread successfully acquires the read-write lock, if the time for the third thread to wait for the lock is greater than or equal to a second threshold, outputting blocking information of a fourth thread; the time for waiting for the lock is the time point when the third thread successfully acquires the read-write lock minus the time point when the third thread applies for the read-write lock; the fourth thread holds the read-write lock during the process of the third thread waiting for the read-write lock.

6. The method according to claim 1, wherein The outputting the blocking information of the first thread includes: Determining a blocking reason according to the blocking information of the first thread; the blocking reason includes resources used by a process executed during the lock-holding period of the first thread and / or hardware used by the process; Outputting the blocking reason.

7. The method according to claim 6, characterized in that, The outputting the blocking reason includes: Outputting the blocking reason through one or more of an operating system OS, a BMC, and a basic input / output system BIOS.

8. A computing device, characterized in that, The computing device includes a memory and at least one processor, and the memory is used to store a set of computer instructions; when the processor executes the set of computer instructions, executing the method for obtaining thread read-write blocking information according to any one of claims 1-7 above.

Citation Information

Patent Citations

  • Function execution timeout and deadlock detection method based on dynamic tracking of operating period

    CN104636259A

  • Thread blockage detection method and device

    CN109992436A

  • Thread control method, thread control device and storage medium

    CN113778696A