path: root/.tsan-suppressions
diff options
authorMatheus Tavares <>2020-01-16 02:39:52 (GMT)
committerJunio C Hamano <>2020-01-17 21:52:14 (GMT)
commitb1fc9da1c84a94ef03eb07df361f3ec43006b39f (patch)
tree690e752f40991e17caf26cf68598010877ab644b /.tsan-suppressions
parentd5b0bac52841857b5ba197ca931ecf729fdbc63e (diff)
replace-object: make replace operations thread-safe
replace-object functions are very close to being thread-safe: the only current racy section is the lazy initialization at prepare_replace_object(). The following patches will protect some object reading operations to be called threaded, but before that, replace functions must be protected. To do so, add a mutex to struct raw_object_store and acquire it before lazy initializing the replace_map. This won't cause any noticeable performance drop as the mutex will no longer be used after the replace_map is initialized. Later, when the replace functions are called in parallel, thread debuggers might point our use of the added replace_map_initialized flag as a data race. However, as this boolean variable is initialized as false and it's only updated once, there's no real harm. It's perfectly fine if the value is updated right after a thread read it in replace-map.h:lookup_replace_object() (there'll only be a performance penalty for the affected threads at that moment). We could cease the debugger warning protecting the variable reading at the said function. However, this would negatively affect performance for all threads calling it, at any time, so it's not really worthy since the warning doesn't represent a real problem. Instead, to make sure we don't get false positives (at ThreadSanitizer, at least) an entry for the respective function is added to .tsan-suppressions. Signed-off-by: Matheus Tavares <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to '.tsan-suppressions')
1 files changed, 6 insertions, 0 deletions
diff --git a/.tsan-suppressions b/.tsan-suppressions
index 8c85014..5ba86d6 100644
--- a/.tsan-suppressions
+++ b/.tsan-suppressions
@@ -8,3 +8,9 @@
# in practice it (hopefully!) doesn't matter.
+# A boolean value, which tells whether the replace_map has been initialized or
+# not, is read racily with an update. As this variable is written to only once,
+# and it's OK if the value change right after reading it, this shouldn't be a
+# problem.