title: Does the C++ volatile keyword introduce a memory fence?
body: <p>I understand that <code>volatile</code> informs the compiler that the value may be changed, but in order to accomplish this functionality, does the compiler need to introduce a memory fence to make it work?</p>
  
  <p>From my understanding, the sequence of operations on volatile objects cannot be reordered and must be preserved. This seems to imply some memory fences are necessary and that there isn't really a way around this. Am I correct in saying this?</p>
  
  <hr>
  
  <p>There is an interesting discussion at <a href="https://stackoverflow.com/questions/14785639/may-accesses-to-volatiles-be-reordered">this related question</a></p>
  
  <p><a href="https://stackoverflow.com/a/14789387/321013">Jonathan Wakely writes</a>:</p>
  
  <blockquote>
    <p>... Accesses to distinct volatile variables cannot be reordered by the
    compiler as long as they occur in separate full expressions ... right
    that volatile is useless for thread-safety, but not for the reasons he
    gives. It's not because the compiler might reorder accesses to
    volatile objects, but because the CPU might reorder them. Atomic
    operations and memory barriers prevent the compiler and the CPU from
    reordering</p>
  </blockquote>
  
  <p>To which <a href="https://stackoverflow.com/users/721269/david-schwartz">David Schwartz</a> replies <a href="https://stackoverflow.com/questions/14785639/may-accesses-to-volatiles-be-reordered?lq=1#comment20732711_14789387">in the comments</a>:</p>
  
  <blockquote>
    <p>... There's no difference, from the point of view of the C++ standard,
    between the compiler doing something and the compiler emitting
    instructions that cause the hardware to do something. If the CPU may
    reorder accesses to volatiles, then the standard doesn't require that
    their order be preserved. ...</p>
    
    <p>... The C++ standard doesn't make any distinction about what does the
    reordering. And you can't argue that the CPU can reorder them with no
    observable effect so that's okay -- the C++ standard defines their
    order as observable. A compiler is compliant with the C++ standard on
    a platform if it generates code that makes the platform do what the
    standard requires. If the standard requires accesses to volatiles not
    be reordered, then a platform the reorders them isn't compliant. ...</p>
    
    <p>My point is that if the C++ standard prohibits the compiler from
    reordering accesses to distinct volatiles, on the theory that the
    order of such accesses is part of the program's observable behavior,
    then it also requires the compiler to emit code that prohibits the CPU
    from doing so. The standard does not differentiate between what the
    compiler does and what the compiler's generate code makes the CPU do.</p>
  </blockquote>
  
  <p>Which does yield two questions: Is either of them "right"? What do actual implementations really do?</p>