Atomicity of C# Coalescing Operator

Question

I ran into some singleton code today in our codebase and I wasn't sure if the following was thread-safe:

public static IContentStructure Sentence{ 
    get {
       return _sentence ?? (_sentence = new Sentence()); 
    }
}

This statement is equivalent to:

if (_sentence != null) {
       return _sentence;
}
else {
    return (_sentence = new Sentence());
}

I believe that ?? is just a compiler trick and that the resulting code is still NOT atomic. In other words, two or more threads could find _sentence to be null before setting _sentence to a new Sentence and returning it.

To guarantee atomicity, we'd have to lock that bit of code:

public static IContentStructure Sentence{ 
    get {

       lock (_sentence) { return _sentence ?? (_sentence = new Sentence()); }
    }
}

Is that all correct?

Answer 1

I ran into some singleton code today in our codebase

Do you have such obfuscated code throughout your codebase? This code does the same thing:

if (_s == null) 
    _s = new S();
return _s;

and is about a thousand times easier to read.

I believe that ?? is just a compiler trick and that the resulting code is still NOT atomic

You are correct. C# makes the following guarantees of atomicity:

Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list are also atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic. Aside from the library functions designed for that purpose, there is no guarantee of atomic read-modify-write, such as in the case of increment or decrement.

The null coalescing operator is not on that list of guarantees.

To guarantee atomicity, we'd have to lock that bit of code:

lock (_sentence) { return _sentence ?? (_sentence = new Sentence()); } } }    

Good heavens no. That crashes immediately!

The correct thing to do is one of:

• Stop trying to write multithreaded code.
• Write a singleton using one of the safe singleton patterns Jon Skeet documents on his page about singletons.
• Use the Lazy<T> class.
• Lock on an object dedicated to locking that variable.
• Use an Interlocked Compare Exchange to do an atomic test and set.