<div class="gmail_quote">On Fri, Apr 8, 2011 at 7:38 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Apr 8, 2011 at 6:09 PM, Dave Zarzycki <<a href="mailto:zarzycki@apple.com" class="cremed">zarzycki@apple.com</a>> wrote:<br>
> Background:<br>
><br>
> The __sync_*() atomic intrinsics do not directly expose the fundamental atomic swap operation that many processors support. One can indirectly get at the instruction by using __sync_lock_test_and_set(), but the documentation for that intrinsic does not promise to be an atomic swap on all architectures or even be a full barrier like the other __sync_*() intrinsics. This patch fixes this oversight:<br>

<br>
</div>It's not really an oversight; the __sync_ intrinsics were invented by<br>
Intel for Itanium, and the Itanium xchg instruction isn't a full<br>
barrier.  I don't see any harm in adding this anyway, although I'm not<br>
really an expert in lock-free algorithms.</blockquote></div><br><div>While I don't see anything directly problematic with this, I think it might be better to instead look toward adding a complete set of builtins through which both the C++11 and C1X atomic libraries can be implemented. Until those are added, it's not clear to me what value this intrinsic adds over inline asm. Typically the advantage is portability, but that doesn't seem likely to be achieved at this point for any of the __sync_* functions, and much more likely to be achieved through C1X and C++11 standard libraries...</div>
<div><br></div><div>Just my 2 cents.</div>