Question

This question is NOT about race-conditions, atomicity, or why you should use locks in your code. I already know about those.

UPDATE: My question isn’t ‘does weirdness with volatile memory exist’ (i know it does), my question is ‘doesn’t the .NET runtime abstract that away so you’ll never see it’.

See http://www.yoda.arachsys.com/csharp/threads/volatility.shtml and the first answer on Is a string property itself threadsafe?

(They’re really the same article since one references the other.) One thread sets a bool and the other thread loops forever reading that bool — those articles claim the reading thread might cache the old value and never read the new value, so therefore you need a lock (or use the volatile keyword). They claim the following code will potentially loop forever. Now I agree it’s good practice to lock your variables, but I can’t believe the .NET runtime would really ignore a memory value changing as the article claims. I understand their talk about volatile memory vs non-volatile memory, and I agree they have a valid point in non-managed code, but I can’t believe the .NET runtime won’t correctly abstract that away so that the following code does what you expect. The article even admits the code will ‘almost certainly’ work (though not guaranteed), so I’m calling BS on the claim. Can anyone verify that it’s true the following code won’t always work? Is anyone able to get even one case (maybe you can’t always reproduce it) where this fails?

class BackgroundTaskDemo {     private bool stopping = false;      static void Main()     {         BackgroundTaskDemo demo = new BackgroundTaskDemo();         new Thread(demo.DoWork).Start();         Thread.Sleep(5000);         demo.stopping = true;     }      static void DoWork()     {          while (!stopping)          {                // Do something here          }     } } 

Answer 1

The point is: it might work, but it isn’t guaranteed to work by the spec. What people are usually after is code that works for the right reasons, rather than working by a fluke combination of the compiler, the runtime and the JIT, which might change between framework versions, the physical CPU, the platform, and things like x86 vs x64.

Understanding the memory model is a very very complex area, and I don’t claim to be an expert; but people who are real experts in this area assure me that the behaviour you are seeing is not guaranteed.

You can post as many working examples as you like, but unfortunately that doesn’t prove much other than ‘it usually works’. It certainly doesn’t prove that it is guaranteed to work. It would only take a single counter-example to disprove, but finding it is the problem…

No, I don’t have one to hand.

---

Update with repeatable counter-example:

using System.Threading; using System; static class BackgroundTaskDemo {     // make this volatile to fix it     private static bool stopping = false;      static void Main()     {         new Thread(DoWork).Start();         Thread.Sleep(5000);         stopping = true;           Console.WriteLine('Main exit');         Console.ReadLine();     }      static void DoWork()     {         int i = 0;         while (!stopping)         {             i++;         }          Console.WriteLine('DoWork exit ' + i);     } } 

Output:

Main exit 

but still running, at full CPU; note that stopping has been set to true by this point. The ReadLine is so that the process doesn’t terminate. The optimization seems to be dependent on the size of the code inside the loop (hence i++). It only works in ‘release’ mode obviously. Add volatile and it all works fine.