title: Memory barriers force cache coherency?
body: <p>I was reading <a href="https://stackoverflow.com/questions/6995310/is-volatile-bool-for-thread-control-considered-wrong">this question about using a bool for thread control</a> and got intrigued by this answer by @eran:</p>
  <blockquote>
  <p>Using volatile is enough only on single cores, where all threads use the same cache. On multi-cores, if stop() is called on one core and run() is executing on another, it might take some time for the CPU caches to synchronize, which means two cores might see two different views of isRunning_.</p>
  <p><strong>If you use synchronization mechanisms, they will ensure all caches get the same values, in the price of stalling the program for a while. Whether performance or correctness is more important to you depends on your actual needs.</strong></p>
  </blockquote>
  <p>I have spent over an hour searching for some statement that says synchronization primitives force cache coherency but have failed.  The closest I have come is <a href="https://en.wikipedia.org/wiki/Memory_barrier#Out-of-order_execution_versus_compiler_reordering_optimizations" rel="noreferrer">Wikipedia</a>:</p>
  <blockquote>
  <p>The keyword volatile does not guarantee a memory barrier to enforce cache-consistency.</p>
  </blockquote>
  <p>Which suggests that memory barriers do force cache consistency, and since some synchronization primitives are implemented using memory barriers (again from Wikipedia) this is some &quot;evidence&quot;.</p>
  <p>But I don't know enough to be certain whether to believe this or not, and be sure that I'm not misinterpreting it.</p>
  <p>Can someone please clarify this?</p>