Static data race analysis of at least a portion of a multi-threaded application in order to identify potential data race defects in the multi-threaded application. The static data race analysis includes intra-component static analysis as well as inter-component static analysis. The intra-component static analysis for a given component involves identifying a set of memory accesses operations in the component. For each of at least one of the set of memory access operations, the analysis determines whether there is a data race protection element associated with the memory access command.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A computer program product comprising one or more computer storage media having thereon computer-executable instructions that are structured such that, when executed by one or more processors of a computing system, cause the computing system to perform a method for performing static data race analysis of at least a portion of a multi-threaded application in order to identify potential data race defects in the multi-threaded application, the method comprising: an act of performing intra-component static analysis for at least a plurality of components of the multi-threaded application, the intra-component analysis comprising the following for each of at least some of the plurality of components: an act of identifying a set of memory access operations in the component; and for each of the memory access operations in the set of memory access operations in the component, performing the following: an act of determining whether there is a data race protection element associated with the memory access operation; and an act of performing inter-component static analysis on the plurality of components.
A software tool for finding potential data race bugs in multi-threaded applications. It analyzes the application's code in two stages: first, it analyzes each component (e.g., a class or module) individually to identify all memory access operations (reads and writes). For each memory access, it checks if there's a data race protection mechanism in place, like a lock or other synchronization primitive. Second, it performs inter-component analysis to analyze interactions between different components. The tool reports potential data races it finds during these analyses.
2. The computer program product in accordance with claim 1 , wherein the act of performing inter-component static analysis comprises the following for each of at least some of the plurality of components for at least one parameter of the corresponding component: an act of determining a type of operation a caller component performs on the parameter of the component; an act of determining a type of operation that an associated callee component performs on the parameter of the component; and an act of reconciling the determinations of the two types of operation to identify whether the operation is protected from a data race.
In the data race detection tool described previously, the inter-component analysis works by examining how different components interact through function or method parameters. For each parameter, the tool determines what type of operation the calling component performs on it (read or write) and what type of operation the called component performs. Then, it reconciles these two types of operations to determine if the parameter is accessed in a way that's protected from data races. If the caller and callee both write to the same memory location pointed by the parameter without proper synchronization, it flags a potential race.
3. The computer program product in accordance with claim 2 , wherein the act of reconciling inlines code from the callee component into code of the caller component.
In the data race detection tool described previously, when reconciling data access operations between calling and called components, the analysis inlines the code of the called component into the code of the calling component. This allows the tool to analyze the combined code as a single unit, making it easier to identify potential data races that might occur due to the interaction between the two components.
4. The computer program product in accordance with claim 2 , wherein the act of reconciling does not devirtualize virtual function calls.
In the data race detection tool described previously, when reconciling data access operations between calling and called components, the analysis does *not* perform devirtualization of virtual function calls. It respects the dynamic dispatch of virtual functions, meaning it doesn't try to resolve the specific implementation that will be called at runtime. This ensures the analysis remains sound even in the presence of polymorphism.
5. The computer program product in accordance with claim 1 , wherein the data race protection element for a given memory access is that the memory access is protected by a lock.
In the data race detection tool described previously, the "data race protection element" can be a lock. This means that if a memory access is protected by a lock (e.g., a mutex or semaphore) that prevents concurrent access from multiple threads, the tool considers it safe from data races. The tool identifies memory accesses occurring within critical sections protected by locks.
6. The computer program product in accordance with claim 5 , wherein the intra-component static analysis does not match a lock object associated with the lock to a protected memory location.
In the data race detection tool described previously, the intra-component static analysis does *not* try to precisely match a lock object to the specific memory location it protects. Instead, it generally recognizes the presence of a lock without necessarily understanding the exact memory region the lock guards. This avoids the complexity of alias analysis within components.
7. The computer program product in accordance with claim 1 , wherein the data race protection element for a given memory access operation is that the memory access is a volatile memory access in which a compiler is signaled to not reorder the memory access operation.
In the data race detection tool described previously, the "data race protection element" can be a `volatile` memory access. The `volatile` keyword signals to the compiler not to reorder the memory access operation, ensuring that it happens in the order specified in the code. This can prevent certain types of data races.
8. The computer program product in accordance with claim 1 , wherein the data race protection element for a first memory access is that the first memory access is protected by a lock, and wherein the data race protection element for a second memory access is that the second memory access is a volatile memory access.
In the data race detection tool described previously, a memory access can be protected by either a lock *or* by being declared `volatile`. The analysis recognizes both mechanisms as ways to prevent data races. One memory access might be protected by a lock while another memory access might be a volatile access.
9. The computer program product in accordance with claim 8 , wherein the first memory access and the second memory access in the plurality of components such that, during execution, the second memory access occurs before the first memory access.
In the data race detection tool described previously, it is possible to have one memory access protected by a lock and another memory access declared as `volatile` such that, during program execution, the `volatile` access *occurs before* the lock-protected access. This order of operations can influence whether a data race might occur.
10. The computer program product in accordance with claim 8 , wherein the first memory access and the second memory access in the plurality of components such that, during execution, the second memory access occurs after the first memory access.
In the data race detection tool described previously, it is possible to have one memory access protected by a lock and another memory access declared as `volatile` such that, during program execution, the `volatile` access *occurs after* the lock-protected access. This order of operations can influence whether a data race might occur.
11. The computer program product in accordance with claim 1 , wherein the plurality of components are in intermediate code.
In the data race detection tool described previously, the components being analyzed can be in an *intermediate code* format (like bytecode or LLVM IR). This allows the tool to analyze code that has already been compiled from source code, enabling analysis across different programming languages that compile to the same intermediate representation.
12. The computer program product in accordance with claim 11 , wherein the set of memory access operations are explicit in the intermediate code.
In the data race detection tool described previously, if the analysis operates on intermediate code, the memory access operations are *explicit* in the intermediate code. This means that the intermediate code representation directly identifies memory reads and writes, making it easier for the tool to locate them during the analysis.
13. The computer program product in accordance with claim 1 , wherein the plurality of components are in source code.
In the data race detection tool described previously, the components being analyzed can be in *source code* format. This allows the tool to analyze code directly, without requiring it to be compiled first.
14. The computer program product in accordance with claim 1 , wherein the intra-component analysis further comprises the following for each of at least some of plurality of components: an act of performing a reaching analysis on the set of memory access operations to determine whether the corresponding accessed data is known globally accessible, or accessed from a function parameter.
In the data race detection tool described previously, the intra-component analysis performs a "reaching analysis" to determine if the data being accessed by a memory access operation is globally accessible or accessed via a function parameter. This helps determine the scope and potential sharing of the data.
15. The computer program product in accordance with claims 14 , wherein if, for a particular memory access operation, the corresponding accessed data is not determined to be known globally accessible, and is not determined to be accessed from a function parameter, the corresponding accessed data is assumed to be only locally accessible.
In the data race detection tool described previously, during the intra-component analysis, if the tool cannot determine that a memory access operation is accessing globally accessible data or data from a function parameter, it assumes the accessed data is only accessible locally within the component. This helps reduce false positives by limiting the scope of potential data races.
16. The computer program product in accordance with claim 14 , wherein the intra-component analysis does not do alias analysis to determine all the ways the corresponding accessed data may be accessed.
In the data race detection tool described previously, the intra-component analysis does *not* perform alias analysis to determine all the possible ways that the data being accessed might be accessed. This is a simplification to improve performance, as alias analysis can be computationally expensive.
17. A method for performing static data race analysis of at least a portion of a multi-threaded application in order to identify potential data race defects in the multi-threaded application, the method comprising: an act of performing intra-component static analysis of a multi-threaded application; and an act of performing inter-component static analysis on the plurality of components, wherein the act of performing inter-component static analysis comprises the following for each of at least some of the plurality of components for at least one parameter of the corresponding component: an act of determining a type of operation a caller component performs on the parameter of the component; an act of determining a type of operation that an associated callee component performs on the parameter of the component; and an act of reconciling the determinations of the two types of operation to identify whether the operation is protected from a data race.
A method for detecting potential data race bugs in multi-threaded applications comprises performing static analysis. The method analyzes code in two phases: intra-component analysis of each component, and inter-component analysis. Inter-component analysis checks how calling and called components interact with function or method parameters. For each parameter, the tool determines the type of operation the calling component performs, the type of operation the called component performs, and then reconciles these operations to determine if the parameter is protected from a data race.
18. The method in accordance with claim 17 , wherein the act of reconciling inlines code from the callee component into code of the caller component.
In the data race detection method described previously, when reconciling data access operations between calling and called components, the method inlines the code of the called component into the code of the calling component. This allows the analysis to treat the combined code as a single unit, making it easier to identify potential data races.
19. The method in accordance with claim 17 , wherein the act of reconciling does not devirtualize virtual function calls.
In the data race detection method described previously, when reconciling data access operations between calling and called components, the method does *not* devirtualize virtual function calls. It respects the dynamic dispatch of virtual functions, ensuring the analysis is sound even with polymorphism.
20. A computer program product comprising one or more computer storage media having thereon computer-executable instructions that are structured such that, when executed by one or more processors of a computing system, cause the computing system to perform a method for performing static data race analysis of at least a portion of a multi-threaded application in order to identify potential data race defects in the multi-threaded application, the method comprising: an act of performing intra-component static analysis for at least a plurality of components of the multi-threaded application, the intra-component analysis comprising the following for each of at least some of plurality of components: an act of identifying a set of memory access operations in the component; and for each of the memory access operations in the set of memory access operations in the component, performing the following: an act of determining whether there is a data race protection element associated with the memory access command; and an act of performing inter-component static analysis on the plurality of components, wherein the act of performing inter-component static analysis comprises the following for each of at least some of the plurality of components for at least one parameter of the corresponding component: an act of determining a type of operation a caller component performs on the parameter of the component; an act of determining a type of operation that an associated callee component performs on the parameter of the component; and an act of reconciling the determinations of the two types of operation to identify whether the operation is protected from a data race.
A software tool for finding potential data race bugs in multi-threaded applications. It analyzes the application's code in two stages: first, it analyzes each component individually to identify all memory access operations (reads and writes). For each memory access, it checks if there's a data race protection mechanism in place, like a lock or other synchronization primitive. Second, it performs inter-component analysis to analyze interactions between different components. Inter-component analysis works by examining how different components interact through function or method parameters. For each parameter, the tool determines what type of operation the calling component performs on it (read or write) and what type of operation the called component performs. Then, it reconciles these two types of operations to determine if the parameter is accessed in a way that's protected from data races. The tool reports potential data races it finds during these analyses.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
March 2, 2011
August 13, 2013
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.