title: How does a mutex lock and unlock functions prevents CPU reordering?
body: <p>As far as I know, a function call acts as a compiler barrier, but not as a CPU barrier.</p>
  
  <p>This <a href="http://preshing.com/20120913/acquire-and-release-semantics/" rel="nofollow noreferrer">tutorial</a> says the following:</p>
  
  <blockquote>
    <p>acquiring a lock implies acquire semantics, while releasing a lock
    implies release semantics! All the memory operations in between are
    contained inside a nice little barrier sandwich, preventing any
    undesireable memory reordering across the boundaries.</p>
  </blockquote>
  
  <p>I assume that the above quote is talking about CPU reordering and not about compiler reordering.</p>
  
  <p>But I don't understand how does a mutex lock and unlock causes the CPU to give these functions acquire and release semantics.</p>
  
  <p>For example, if we have the following C code:</p>
  
  <pre><code>pthread_mutex_lock(&amp;lock);
  i = 10;
  j = 20;
  pthread_mutex_unlock(&amp;lock);
  </code></pre>
  
  <p>The above C code is translated into the following (pseudo) assembly instructions:</p>
  
  <pre><code>push the address of lock into the stack
  call pthread_mutex_lock()
  mov 10 into i
  mov 20 into j
  push the address of lock into the stack
  call pthread_mutex_unlock()
  </code></pre>
  
  <p>Now what prevents the CPU from reordering <code>mov 10 into i</code> and <code>mov 20 into j</code>  to above <code>call pthread_mutex_lock()</code> or to below <code>call pthread_mutex_unlock()</code>?</p>
  
  <p>If it is the <code>call</code> instruction that prevents the CPU from doing the reordering, then why is the tutorial I quoted makes it seem like it is the mutex lock and unlock functions that prevents the CPU reordering, why the tutorial I quoted didn't say that any function call will prevent the CPU reordering?</p>
  
  <p><em>My question is about the x86 architecture.</em></p>