Question

Is there any reason why you would create locks around the getter and setter of a boolean property like this?

  private _lockObject = new object();
  private bool _myFlag;
  public bool MyFlag
  {
    get
    {
      lock (_lockObject)
      {
        return _myFlag;
      }
    }
    set
    {
      lock (_lockObject)
      {
        _myFlag = value;
      }
    }
  }

Answer 1

Well, you don’t need locks necessarily – but if you want one thread to definitely read the value that another thread has written, you either need locks or a volatile variable.

I’ve personally given up trying to understand the precise meaning of volatile. I try to avoid writing my own lock-free code, instead relying on experts who really understand the memory model.

EDIT: As an example of the kind of problem this can cause, consider this code:

using System;
using System.Threading;

public class Test
{
    private static bool stop = false;

    private bool Stop
    {
        get { return stop; }
        set { stop = value; }
    }

    private static void Main()
    {
        Thread t = new Thread(DoWork);
        t.Start();
        Thread.Sleep(1000); // Let it get started
        Console.WriteLine("Setting stop flag");
        Stop = true;
        Console.WriteLine("Set");
        t.Join();
    }

    private static void DoWork()
    {
        Console.WriteLine("Tight looping...");
        while (!Stop)
        {
        }
        Console.WriteLine("Done.");
    }
}

That program may or may not terminate. I’ve seen both happen. There’s no guarantee that the “reading” thread will actually read from main memory – it can put the initial value of stop into a register and just keep using that forever. I’ve seen that happen, in reality. It doesn’t happen on my current machines, but it may do on my next.

Putting locks within the property getter/setter as per the code in the question would make this code correct and its behaviour predictable.

For more on this, see this blog post by Eric Lippert.