<html><head><base href="x-msg://2854/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Jay, I don't understand your issues here.</div><div><br></div><div>On 12 Feb 2010, at 09:20, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">"m3back atomics summary"<br><br>After a while of looking at this, I conclude<br>that the atomics interface has a bunch<br>of functionality that doesn't map all that<br>well to what x86 provides, and vice versa.<br> <br><br>In particular x86 allows<br> lock mem or reg<br> lock mem xor reg<br> lock mem and reg<br> lock not mem<br> lock neg mem<br> and several others<br> <br><br>but the requirement of the atomic interface<br>to return the new value makes these not line up.<br></div></span></blockquote><div><br></div><div>Which new value? There is no *requirement* that CompareSwap return the actual value in the register:</div><div><br></div><div><div> The CompareSwap operation may fail spuriously, that is return false while</div><div> leaving the value in "expected" unchanged. A consequence of spurious</div><div> failure is that nearly all uses of CompareSwap will be in a loop:</div><div><br></div></div><br><blockquote type="cite"><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">The new value doesn't come back in a register<br>and rereading memory will not be atomic.<br></div></blockquote><div><br></div><div>Again, I don't understand this.</div><br><blockquote type="cite"><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; "> Now I see why the C compiler's _InterlockedOr and such<br>use _InterlockedCompareExchange in a small loop.<br><br> <br>Any xchg with a memory operand on x86 is always atomic.<br> <br> <br>fetch_and_op for add/sub can probably be more efficient using xadd.<br>You get back the old value but you can do the add a second time.<br> <br> <br>I understand the point isn't necessarily to expose whatever x86 can do,<br>but also to provide an interface that can be reasonably implemented<br>across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k).<br> <br> <br>It's possible the front end (or backend) should notice if the return value<br>is ignored, such as by preceding it with EVAL, and then those can be<br>implemented more efficiently.<br>The NT386 backend does not have the level of sophistication required to do that.<br> <br> <br>I'm torn on even providing this stuff.<br>It's all very tricky to use.<br>However any "systems" language should probobably<br>provide for a portable efficient lock package, that<br>others can then easily use.<br> <br><br> - Jay<br><br></div></blockquote></div><br></body></html>