C# are field reads guaranteed to be reliable (fresh) when using multithreading?

Question

Background

My colleague thinks reads in multithreaded C# are reliable and will always give you the current, fresh value of a field, but I've always used locks because I was sure I'd experienced problems otherwise. I spent some time googling and reading articles, but I mustn't be able to provide google with correct search input, because I didn't find exactly what I was after.

So I wrote the below program without locks in an attempt to prove why that's bad.

Question

I'm assuming the below is a valid test, then the results show that the reads aren't reliable/fresh.

Can someone explain what this is caused by? (reordering, staleness or something else)?

And link me to official Microsoft documentation/section explaining why this happens and what is the recommended solution?

If the below isn't a valid test, what would be?

Program

If there are two threads, one calls SetA and the other calls SetB, if the reads are unreliable without locks, then intermittently Foo's field "c" will be false.

using System;
using System.Threading.Tasks;

namespace SetASetBTestAB
{
    class Program
    {
        class Foo
        {
            public bool a;
            public bool b;
            public bool c;

            public void SetA()
            {
                a = true;
                TestAB();
            }

            public void SetB()
            {
                b = true;
                TestAB();
            }

            public void TestAB()
            {
                if (a && b)
                {
                    c = true;
                }
            }
        }

        static void Main(string[] args)
        {
            int timesCWasFalse = 0;
            for (int i = 0; i < 100000; i++)
            {
                var f = new Foo();
                var t1 = Task.Run(() => f.SetA());
                var t2 = Task.Run(() => f.SetB());
                Task.WaitAll(t1, t2);
                if (!f.c)
                {
                    timesCWasFalse++;
                }
            }
            Console.WriteLine($"timesCWasFalse: {timesCWasFalse}");
            Console.WriteLine("Finished. Press Enter to exit");
            Console.ReadLine();
        }
    }
}

Output

Release mode. Intel Core i7 6700HQ:

Run 1: timesCWasFalse: 8

Run 2: timesCWasFalse: 10

Answer 1

Of course it is not fresh. The average CPU nowadays has 3 layers of Caches between each cores Registers and the RAM. And it can take quite some time for a write to one cache to be propagate to all of them.

And then there is the JiT Compiler. Part of it's job is dead code dection. And one of the first things it will do is cut out "useless" variables. For example this code tried to force a OOM excpetion by running into the 2 GiB Limit on x32 Systems:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OOM_32_forced
{
    class Program
    {
        static void Main(string[] args)
        {
            //each short is 2 byte big, Int32.MaxValue is 2^31.
            //So this will require a bit above 2^32 byte, or 2 GiB
            short[] Array = new short[Int32.MaxValue];

            /*need to actually access that array
            Otherwise JIT compiler and optimisations will just skip
            the array definition and creation */
            foreach (short value in Array)
                Console.WriteLine(value);
        }
    }
}

The thing is that if you cut out the output stuff, there is a decent chance that the JiT will remove the variable Array inlcuding the instantionation order. The JiT has a decent chance to reduce this programming to doing nothing at all at runtime.

volatile is first preventing the JiT from doing any optimisations on that value. And it might even have some effect on how the CPU processes stuff.