<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote:</div><blockquote type="cite"><div>unfortunately, race detectors like helgrind don't like this kind of<br>thing, and report it as a race. Last time I asked about it I was<br>told that fixing it would be too hard/expensive.<br></div></blockquote><div><br></div><div>I know, and it's somewhat unfortunate. However, this path is extremely hot in</div><div>LLC, and was significantly contended using only two threads. I don't have a</div><div>non-contended solution offhand.</div><br><blockquote type="cite"><div><blockquote type="cite"> VTs[VT.getSimpleVT().SimpleTy] = VT;<br></blockquote><blockquote type="cite">- return &VTs[VT.getSimpleVT().SimpleTy];<br></blockquote><blockquote type="cite">+ sys::MemoryFence();<br></blockquote><br>I don't think this fence actually does anything useful unless<br>users of the pointer do a fence before reading the contents<br>of the pointer. That said, I think alpha is the only platform<br>where you have to worry about this kind of pointer vs pointee<br>race.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>I'm fairly sure that the only things that dereference into the array</div><div>are callers of this method, who dereference it through the returned</div><div>pointer. The purpose of the fence is to guarantee that the valid has</div><div>been written before the pointer is returned to the caller.</div><div><br></div><div>--Owen</div></body></html>