title: Is the 'volatile' keyword still broken in C#?
body: <p>Joe Albahari has a <a href="http://www.albahari.com/threading/" rel="noreferrer">great series</a> on multithreading that's a must read and should be known by heart for anyone doing C# multithreading.</p>
  
  <p>In part 4 however he mentions the problems with volatile:</p>
  
  <blockquote>
    <p>Notice that applying volatile doesn’t prevent a write followed by a
    read from being swapped, and this can create brainteasers. Joe Duffy
    illustrates the problem well with the following example: if Test1 and
    Test2 run simultaneously on different threads, it’s possible for a and
    b to both end up with a value of 0 (despite the use of volatile on
    both x and y)</p>
  </blockquote>
  
  <p>Followed by a note that the MSDN documentation is incorrect:</p>
  
  <blockquote>
    <p>The MSDN documentation states that use of the volatile keyword ensures
    that the most up-to-date value is present in the field at all times.
    This is incorrect, since as we’ve seen, a write followed by a read can
    be reordered.</p>
  </blockquote>
  
  <p>I've checked the <a href="https://msdn.microsoft.com/en-us/library/x13ttww7.aspx" rel="noreferrer">MSDN documentation</a>, which was last changed in 2015 but still lists:</p>
  
  <blockquote>
    <p>The volatile keyword indicates that a field might be modified by
    multiple threads that are executing at the same time. Fields that are
    declared volatile are not subject to compiler optimizations that
    assume access by a single thread. <strong>This ensures that the most
    up-to-date value is present in the field at all times</strong>.</p>
  </blockquote>
  
  <p>Right now I still avoid volatile in favor of the more verbose to prevent threads using stale data:</p>
  
  <pre><code>private int foo;
  private object fooLock = new object();
  public int Foo {
      get { lock(fooLock) return foo; }
      set { lock(fooLock) foo = value; }
  }
  </code></pre>
  
  <p>As the parts about multithreading were written in 2011, is the argument still valid today? Should volatile still be avoided at all costs in favor of locks or full memory fences to prevent introducing very hard to produce bugs that as mentioned are even dependent on the CPU vendor it's running on?</p>