Is the 'volatile' keyword still broken in C#? : <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>
