Is the 'volatile' keyword still broken in C#?

31
votes

Joe Albahari has a great series on multithreading that's a must read and should be known by heart for anyone doing C# multithreading.

In part 4 however he mentions the problems with volatile:

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)

Followed by a note that the MSDN documentation is incorrect:

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.

I've checked the MSDN documentation, which was last changed in 2015 but still lists:

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. This ensures that the most up-to-date value is present in the field at all times.

Right now I still avoid volatile in favor of the more verbose to prevent threads using stale data:

private int foo;
private object fooLock = new object();
public int Foo {
    get { lock(fooLock) return foo; }
    set { lock(fooLock) foo = value; }
}

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?

4
c#multithreadingvolatile
What's the point of surrounding return and assignment statement by lock in your example? – Yarik
This is still misleading. Volatile provides acquire/release memory semantics which are enough to implement many algorithms efficiently. Yes it's difficult to use, but that doesn't make it broken (c++'s solution is clearly superior but they had the advantage of seeing the problems with volatile in java) (And anyone who thinks that memory barriers are easier than volatile just have not enough experience with architectures other than x86. Try to use memory barriers on an architecture without multi-copy atomicity and see how far you get) – Voo
(The msdn description is admittedly noticeably worse. Clearly whoever wrote that snippet does not understand volatile at all and one can only hope was never allowed to write a single line of concurrent code) – Voo
@Yarik lock provides full before and after memory fencing. A memory fence ensures the CPU cache is refreshed from memory. For example I use this in a while(!Stopped) for background service work on a separate thread. If the windows service stops, I put Stopped to true so the separate thread jumps out of the loop. Without locking (and thus fencing) the backing field of the property might remain cached in the CPU, will never be refreshed and the thread will never stop. – Drakarah
Currently your locks don't really do anything more than a volatile does, and in any case can't prevent many classes of synchronization problems. Most of these relate to the interleaving of two threads - for instance, attempting to do something like foo++ from two threads simultaneously can still have undefined results, and why should be more obvious given your locking example: there's a separate lock for each the load and store, meaning two threads have to fight over who goes first for each operation (whether this is relevant to your current code using this is unknown at this time). – Clockwork-Muse

4 Answers

32
votes

Volatile in its current implementation is not broken despite popular blog posts claiming such a thing. It is however badly specified and the idea of using a modifier on a field to specify memory ordering is not that great (compare volatile in Java/C# to C++'s atomic specification that had enough time to learn from the earlier mistakes). The MSDN article on the other hand was clearly written by someone who has no business talking about concurrency and is completely bogus.. the only sane option is to completely ignore it.

Volatile guarantees acquire/release semantics when accessing the field and can only be applied to types that allow atomic reads and writes. Not more, not less. This is enough to be useful to implement many lock-free algorithms efficiently such as non-blocking hashmaps.

One very simple sample is using a volatile variable to publish data. Thanks to the volatile on x, the assertion in the following snippet cannot fire:

private int a;
private volatile bool x;

public void Publish()
{
    a = 1;
    x = true;
}

public void Read()
{
    if (x)
    {
        // if we observe x == true, we will always see the preceding write to a
        Debug.Assert(a == 1); 
    }
}

Volatile is not easy to use and in most situations you are much better off to go with some higher level concept, but when performance is important or you're implementing some low level data structures, volatile can be exceedingly useful.

13
votes

As I read the MSDN documentation, I believe it is saying that if you see volatile on a variable, you do not have to worry about compiler optimizations screwing up the value because they reorder the operations. It doesn't say that you are protected from errors caused by your own code executing operations on separate threads in the wrong order. (although admittedly, the comment is not clear as to this.)

2
votes

volatile is a very limited guarantee. It means that the variable isn't subject to compiler optimizations that assume access from a single thread. This means that if you write into a variable from one thread, then read it from another thread, the other thread will definitely have the latest value. Without volatile, one a multiprocessor machine without volatile, the compiler may make assumptions about single-threaded access, for example by keeping the value in a register, which prevents other processors from having access to the latest value.

As the code example you've mentioned shows, it doesn't protect you from having methods in different blocks reordered. In effect volatile makes each individual access to a volatile variable atomic. It doesn't make any guarantees as to the atomicity of groups of such accesses.

If you just want to ensure that your property has an up-to-date single value, you should be able to just use volatile.

The problem comes in if you try to perform multiple parallel operations as if they were atomic. If you have to force several operations to be atomic together, you need to lock the whole operation. Consider the example again, but using locks:

class DoLocksReallySaveYouHere
{
  int x, y;
  object xlock = new object(), ylock = new object();

  void Test1()        // Executed on one thread
  {
    lock(xlock) {x = 1;}
    lock(ylock) {int a = y;}
    ...
  }

  void Test2()        // Executed on another thread
  {
    lock(ylock) {y = 1;}
    lock(xlock) {int b = x;}
    ...
  }
}

The locks cause may cause some synchronization, which may prevent both a and b from having value 0 (I have not tested this). However, since both x and y are locked independently, either a or b can still non-deterministically end up with a value of 0.

So in the case of wrapping the modification of a single variable, you should be safe using volatile, and would not really be any safer using lock. If you need to atomically perform multiple operations, you need to use a lock around the entire atomic block, otherwise scheduling will still cause non-deterministic behavior.

0
votes

Here are some useful disassemblies for volatile in C#: https://sharplab.io/#gist:625b1181356b543157780baf860c9173

On x86 it is just about:

  • using memory instead of registers
  • preventing compiler optimizations like in the case with the endless loop

I use volatile when I just want to tell compiler that a field might be updated from many different threads and I do not need additional features provided by interlocked operations.