<div dir="ltr"><div dir="ltr">On Tue, Jul 30, 2019 at 4:15 PM Billy O'Neal (VC LIBS) <<a href="mailto:bion@microsoft.com">bion@microsoft.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>


<div class="gmail-m_2017408398897453177WordSection1">
<p class="MsoNormal">> we can worry about optimization, perhaps using _Atomic, later</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We can’t use _Atomic because it would not be ABI compatible with our std::atomic; in particular, because we put the spinlock for non-lock-free atomics inside the atomic, for instance. And because that isn’t a thing for some of our supported
 frontends.</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It is possible that there are different intrinsics we could call for Clang that would make you folks happier, but we don’t know what those are or even if they exist at present.</p></div></div></blockquote><div><br></div><div>I was thinking that perhaps the _Atomic_address_as template would do the necessary casts to use it when necessary without changing the storage type inside the std::atomic object.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_2017408398897453177WordSection1"><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">> I think the only downside to using _ReadWriteBarrier, which compiles to an LLVM IR fence, and volatile memory operations</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Also be aware that on Windows there is a lot of code from before the C++ memory model existed, that treats volatile loads as having acquire semantics, hence our `/volatile:ms` switch, which is the default on the platforms that do this for
 `free` (x86 and amd64).</p></div></div></blockquote><div><br></div><div>Right. </div></div></div>