title: Is x86 CMPXCHG atomic, if so why does it need LOCK?
body: <p>The <a href="http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf" rel="noreferrer">Intel documentation</a> says</p>
  <blockquote>
  <p>This instruction can be used with a <code>LOCK</code> prefix to allow the instruction to be executed atomically.</p>
  </blockquote>
  <p>My question is</p>
  <ol>
  <li><p>Can <code>CMPXCHG</code> operate with memory address? From the document it seems not but can anyone confirm that only works with actual VALUE in registers, not memory address?</p>
  </li>
  <li><p>If <code>CMPXCHG</code> isn't atomic and a high level language level CAS has to be implemented through <code>LOCK CMPXCHG</code> (with <code>LOCK</code> prefix), what's the purpose of introducing such an instruction at all?</p>
  </li>
  </ol>
  <p>(I am asking from a high level language perspective. I.e., if the lock-free algorithm has to be translated into a LOCK CMPXCHG on the x86 platform, then it's still prefixed with LOCK. That means the lock-free algorithms are not better than ones with a carefully written synchronized lock / mutex (on x86 at least). This also seems to make the naked CMPXCHG instruction pointless, as I guess the major point for introducing it, was to support such lock-free operations.)</p>