| dc.description.abstract | The built-in race detection tool works dynamically, so it finds races at runtime which can lead to false negatives. The static race detection tool on the other hand analyzes all code regardless of what happens on one particular runtime allowing it to find the races that the dynamic tool cannot. The tool converts the code to SSA code for more easily analyzable data that does not need to be run dynamically. Then, the tool establishes an understanding of what instructions are read or write instructions, and analyzes what instructions have a happens before relation, meaning that one always happens before the other. If a happens before relation is found or the instructions are not either a write and a read instruction or a write and a write instruction, a data race between those two instructions is impossible and can be eliminated. With those baseline conditions, the tool could then be tested on real world data races to progressively make the tool more accurate. In this real-world data race testing, the tool has been quite accurate in ensuring no false negatives occur. The goal of the tool is to have any misreported races be false positives rather than false negatives to improve on the dynamic tool. That goal has been ensured as testing has gone on by reconfiguring the tool to meet that goal. The static tool is, as expected, slower than the dynamic tool due to the nature of static analysis compared to dynamic analysis. However, it brings a new benefit to the race detection tool world by having any errors be false positives while the dynamic tool in contrast gives false negatives. Programmers in Go can now use those two endpoints from the tools to more accurately and thoroughly find races knowing the respective benefits each tool can give separately and in conjunction with each other. | en |
