[Openmp-commits] [PATCH] D108046: tsan: Add new annotation functions to promote all accesses to atomic

Dmitry Vyukov via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Sat Aug 14 23:54:22 PDT 2021

dvyukov added a comment.

> Another possible use case that I see for this kind of annotation is an heuristic "lockset" analysis approach: Assume that no pair of memory accesses under lock has a race, but don't derive HB from the locking. This would allow to find data races currently hidden by the HB introduced from locked regions.

Interesting and I think may be possible.
Do I understand correctly that such mutexes will synchronize memory, but only for the duration of the critical section? A complete support for this may be done by creating a shadow copy of the thread vector clock on mutex lock and then restoring the shadow copy on mutex unlock.
I think there is also a somewhat hacky way to achieve the same in a different way. When we report a race we restore MutexSet for the previous access, and we know the current MutexSet. If there is any intersection for such "lockset" mutex (or maybe just for write-locked mutexes), then we stop reporting the race.
Or, this idea can actually be combined with this change in the following way. We keep most of this change, but don't change the race detection logic itself, but a thread still knows when it's inside of an "atomic section". But we also add atomic section entry/exit to the trace, so that we can restore it for previous memory accesses. Then in ReportRace we check if the current thread is inside of the atomic section and the previous memory access was inside of an atomic section as well.
But this will involve replaying the trace for the other thread, so I am not sure what will be faster creating a shadow vector clock or this... For the new tsan runtime creating a shadow vector clock may be faster, since all vector clocks are fixed size (512 bytes).



More information about the Openmp-commits mailing list