<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 8:54 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1vi" class="a3s" style="overflow:hidden">Hi kcc, samsonov, eugenis,<br>
<br>
Consider the following code:<br>
<br>
P p;<br>
p.x = 1;<br>
p.y = 2;<br>
foo(&p);<br>
<br>
P escapes and so tsan instruments accesses to it. However, before address of the variable is actually taken, it is not shared and so cannot participate in data races. So there is no point in instrumenting these initial memory accesses.</div></blockquote></div><br></div><div class="gmail_extra">There can be races here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Imagine:</div><div class="gmail_extra"><br></div><div class="gmail_extra">foo(P *p) {</div><div class="gmail_extra">  racy_queue.relaxed_atomic_enqueue(p);</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">and then thread B:</div><div class="gmail_extra"><br></div><div class="gmail_extra">bar() {</div><div class="gmail_extra">  P *p = racy_queue.relaxed_atomic_dequeue();</div><div class="gmail_extra">  read(p.x);</div><div class="gmail_extra">  ...</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">Here we don't have a race in my racy_queue because internally it uses relaxed atomics. However it never establishes a happens-before edge, and so the code in bar that reads this should be flagged as a race by TSan.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This isn't just a hypothetical, I have seen TSan catch this in more than one project that had a bad lock-free queue implementation. This is especially dangerous on x86 because the machine instructions used for relaxed store and load are actually enough to establish the necessary memory ordering guarantee.</div><div class="gmail_extra"><br></div><div class="gmail_extra">While we should definitely coalesce the TSan instrumentation to be a single instrumented write preceding the capture, I don't think we should remove this entirely.</div></div>