C# Static Variable access across threads

Question

I am experiencing a bad behavior in my C# Multiple thread program. Some of my static members are loosing their values in other threads, while some statics of the same Declaring Type, do not loose their values.

public class Context {
  public Int32 ID { get; set; }
  public String Name { get; set; }

  public Context(Int32 NewID, String NewName){
      this.ID = NewID;
      this.Name = NewName;
  }
}

public class Root {
    public static Context MyContext;
    public static Processor MyProcessor;

   public Root(){
     Root.MyContext = new Context(1,"Hal");

     if(Root.MyContext.ID == null || Root.MyContext.ID != 1){
         throw new Exception("Its bogus!") // Never gets thrown
     }

     if(Root.MyContext.Name == null || Root.MyContext.Name != "Hal"){
         throw new Exception("It's VERY Bogus!"); // Never gets thrown
     } 

     Root.MyProcessor = new MyProcessor();
     Root.MyProcessor.Start();
   }
}

public class Processor {
   public Processor() {
   }

   public void Start(){
      Thread T= new Thread (()=> {

          if(Root.MyContext.Name == null || Root.MyContext.Name != "Hal"){
                throw new Exception("Ive lost my value!"); // Never gets Thrown
          }

          if(Root.MyContext.ID == null){
              throw new Exception("Ive lost my value!"); // Always gets thrown
          }

      });
   }
}

IS this a thread mutation problem while using static members of certain types?

Answer 1

Use volatile or alternatively access the variables using Interlocked.

The problem you run into is that the compiler (as well as the native compiler) is free to optimize access to the variables as he sees fit without them. So he may dump a variable into a register and just not reread it.

In order to avoid it, you must make sure that the variable is actually REALLY read. Volatile does that. Interlocked does that as well (and allows increment / add etc. to happen atomically).

Which is better you have to decide. Both force a memory barrier onto the processor which does have a non trivial cost when done often. One pattern I use regularly is to have those objects read only mostly, so that I only replace the root object (one memory barrier). Dealing with memory barriers manually (possible, read manual for the keyword) is a pain to get right. It is, though, a lot more efficient - depending how much you do there etc. it may be needed.