Some TSAN failures are not an actual issue as the reader already can accept relaxed memory semantics and there's only a single separate writer thread.

This is the case most notably with all of our metrics. Most of the time the solution performed is to wrap the value in an AtomicWord and perform the operations using that wrapper. However, the writes are performed with strong ordering guarantees that have a slight overhead. These aren't really necessary as there's only one writer thread that is the same throughout the metric's lifetime and the readers can accept relaxed memory semantics.

SERVER-72481 for example found that using AtomicWord semantics for the metrics contributed to a 0.8% regression. The same ticket asks for creating a better version for metrics that generates the same assembly code but explicitly tells TSAN that it's fine.

To avoid the boilerplate process of solving these TSAN failures with AtomicWord we could try to have a class that acts as if it's the normal variable yet offers relaxed atomic semantics. Whenever we encounter a TSAN failure that we can match with this pattern we would simply wrap the type with this class and be done with the change.