Eraser: A Dynamic Data Race Detector for Multithreaded Programs

[Veiasai]

happens-before https://blog.csdn.net/zdxiq000/article/details/60874848

[Veiasai]

Eraser detects data race automatically by monitor the data state. Unfortunately, it's difficult to distinguish the reuse memory access and another thread access. Hence, it needs people explicitly specify the code block which should be checked or not. The more interesting part is experience.

[Veiasai]

• According to the lockset algorithm, when does eraser signal a data race? Why is this condition chosen? When a data enter share-modified state the data race occurs. Because it means the same data was accessed and modified by two different threads. • Under what conditions does Eraser report a false positive? What conditions does it produce false negatives? False Positive: Memory Reuse, Privite Locks, Benign Races False Negative: when set c(v) in read access is removed, concurrent read and write may cause false negatives.

• Typically, instrumenting a program changes the intra-thread timing (the paper calls it interleaving). This can cause bugs to disappear when you start trying to find them. What aspect of the Eraser design mitigates this problem? Eraser is not sensitive to differences in thread interleaving as the experiment showed. I think the discipline used by Eraser makes that. Eraser relies on data state and set of locks instead of happen-before.