Replies: 3 comments
-
I guess that another way to solve this problem could be to define a type of relaxed-atomic references that behaves as non-atomic references except that TSan instrumentation is disabled for their operations. This could be more informative, but it also cannot be used on a record mutable field for example. (If I remember correctly we mentioned adding relaxed atomics to OCaml in the past, and it was remarked that they are not obviously part of the current memory model, which I found surprising as non-atomic references are part of the memory model and have an okay-from-a-distance relaxed behavior. I cannot find the reference to that discussion anymore.) |
Beta Was this translation helpful? Give feedback.
-
The ability to ignore races in a specific functions is useful, especially in OCaml where races can be intentional. Something like an attribute A make-do solution in the meantime is to use environment variables to suppress some reports. |
Beta Was this translation helpful? Give feedback.
-
Since data races have a defined semantics in the OCaml memory model—additionally enjoying the “local data race freedom implies SC” property—I would be tempted to say that non-atomic accesses constitute a de facto equivalent of relaxed atomics. Or am I missing something? |
Beta Was this translation helpful? Give feedback.
-
Is it possible to selectively disable TSan implementation of OCaml code? (cc @OlivierNicole @fabbing)
The use-case I have in mind is to write code that is known to intentionally have benign races. In C code, we can use relaxed atomics for this. In OCaml code, we have to choose between non-atomic references, which will result in a TSan warning, or atomic references, which will be much slower.
Unless I am mistaken, today if I define a library / data structure that uses benign races under the hood, I need to ask my users to not use TSan to detect (other) data races in their program, or at least to be ready to ignore false alarms coming from my own code.
(The specific form of benign races that I was thinking about are the use of a non-atomic "modification count" fields to more reliably detect iterator invalidation in Dynarray, see #11563 (comment) .)
Beta Was this translation helpful? Give feedback.
All reactions