Is replacing the value of a member variable thread safe?

Question

In my application (written in C#) I have an instance of a class with a member variable that points to an instance of another class. This second instance is read-only, so the state of that instance will never change once it is created. But on some occasions I want to replace this instance with a new and updated instance. Is replacing this reference in the first instance safe in a multithreaded environment? Or can this cause a problem?

Answer 1

The simple write operation is in itself thread-safe.

So this is Ok:

x.y = new Y();   // OK

but the following is not:

if (x.y == null)
    x.y = new Y();   // might overwrite a non-null x.y

So it depends on how you want to use it, and what the threads expect. But the atomicity means you'll never have an invalid (half-written) reference in x.y

Answer 2

Yes, it is "safe" in the sense that the reference read/write is atomic. Your client code will always get a valid instance.

Obviously you cannot guarantee that the client code will get the new instance immediately.

Answer 3

Is replacing this reference in the first instance safe in a multithreaded environment?

Sorry to be wishy-washy here, but it depends on how you define "safe".

• It is safe in that it will not corrupt state. This is because reference assignments are atomic.
• It is not safe in that it may lead to unintended behavior.

The unintended behavior can be divided into three broad categories.

• A combination of a read followed by a write may lead to a race condition.
• One thread may not observe changes made by another due to compiler and hardware optimizations.
• One thread may observe a change between two different reads of the reference variable.

Case #1: So in the first case two threads could race to make an assignment under false pretenses. The best example of this is the creation of a singleton.

public static Singleton GetSingleton()
{
  // More than one thread could read null and attempt instantiation here.
  if (instance == null)
  {
    instance = new Singleton();
  }
  return instance;
} 

Case #2: In the second case one thread may continue to read the old instance even though a new instance was published by another thread. Consider this example.

public class Example
{
  private SuperHero hero = new Superman();

  void ThreadA()
  {
    while (true)
    {
      Thread.Sleep(1000);
      hero = new CaptainAmerica();
      Thread.Sleep(1000);
      hero = new GreenLantern();
      Thread.Sleep(1000);
      hero = new IronMan();
    }

  void ThreadB()
  {
    while (true)
    {
      hero.FightTheBadGuys();
    }
  }
}

The problem is that compiler or hardware might optimize ThreadB by "lifting" the read of hero outside of the loop like this.

void ThreadB()
{
  SuperHero local = hero;
  while (true)
  {
    local.FightTheBadGuys();
  }
}

It should not be hard to see that one of our superheros is going to get really tired. Then again, he is a superhero so there may not be a problem afterall. The point I am trying to make here is that this staleness artifact may or may not be a problem depending on your situation.

Case #3: In the third case a thread may incorrectly assume the variable will reference the same instance between two reads.

void SomeThread()
{
  var result1 = instance.DoSomething();
  // The variable instance could get changed here!
  var result2 = instance.DoSomethingElse();
  // Are result1 and result2 in a mutually consistent state here?
}

In the above example result1 and result2 may not be in a mutually consistent state. This is because they were derived from operations running on two different instances. Again, this may or may not be a problem depending on your specific scenario.

Answer 4

Reference replacement is a 32bit integer write operation in 32bit environment and 64bit integer write in 64bit environment respectively. And write operation really performed in two steps:

• Read a new value
• Write a new value

I believe it is not thread safe by default

Answer 5

No, it's not thread-safe because of cache (some architectures needs a memory barrier for something like this), for compiler optimizations and for concurrent access.
You have following choices:

• Declare that field as volatile.
• Use Interlocked.Exchange() to replace the value.

Read MSDN documentation to choose what's better for you (quick: volatile should be faster but you can't save the old value and write the new one in one atomic operation).

EDITED
I think I have to make clear what I mean (many people seem to consider atomic a synonym of thread-safe):

Is replacing this reference in the first instance safe in a multithreaded environment?

No, strictly speaking it's not thread-safe. You don't know what will happen so it can't be safe.

Or can this cause a problem?

It depends on the context. If one thread won't use the correct socket connection (or a closed one) then it'll be a big problem. If one thread won't use the right color for formatting its output then it may not be a problem.

Answer 6

Use following code where you want to update the object with new instance. it is thread safe code.

MyClass obj = null;
Interlocked.CompareExchange(ref obj, new MyClass(), null);