Question

If I have a deeply immutable type (all members are readonly and if they are reference type members, then they also refer to objects that are deeply immutable).

I would like to implement a lazy initialized property on the type, like this:

private ReadOnlyCollection<SomeImmutableType> m_PropName = null; public ReadOnlyCollection<SomeImmutableType> PropName {     get     {         if(null == m_PropName)         {             ReadOnlyCollection<SomeImmutableType> temp = /* do lazy init */;             m_PropName = temp;         }         return m_PropName;     } } 

From what I can tell:

m_PropName = temp;  

…is threadsafe. I’m not worried too much about two threads both racing to initialize at the same time, because it will be rare, both results would be identical from a logical perspective, and I’d rather not use a lock if I don’t have to.

Will this work? What are the pros and cons?

Edit: Thanks for your answers. I will probably move forward with using a lock. However, I’m surprised nobody brought up the possibility of the compiler realizing that the temp variable is unnecessary, and just assigning straight to m_PropName. If that were the case, then a reading thread could possibly read an object that hasn’t finished being constructed. Does the compiler prevent such a situation?

(Answers seem to indicate that the runtime won’t allow this to happen.)

Edit: So I’ve decided to go with an Interlocked CompareExchange method inspired by this article by Joe Duffy.

Basically:

private ReadOnlyCollection<SomeImmutableType> m_PropName = null; public ReadOnlyCollection<SomeImmutableType> PropName {     get     {         if(null == m_PropName)         {             ReadOnlyCollection<SomeImmutableType> temp = /* do lazy init */;             System.Threading.Interlocked(ref m_PropName, temp, null);         }         return m_PropName;     } } 

This is supposed to ensure that all threads that call this method on this object instance will get a reference to the same object, so the == operator will work. It is possible to have wasted work, which is fine – it just makes this an optimistic algorithm.

As noted in some comments below, this depends on the .NET 2.0 memory model to work. Otherwise, m_PropName should be declared volatile.

Answer 1

That will work. Writing to references in C# is guaranteed to be atomic, as described in section 5.5 of the spec. This is still probably not a good way to do it, because your code will be more confusing to debug and read in exchange for a probably minor effect on performance.

Jon Skeet has a great page on implementing singeltons in C#.

The general advice about small optimizations like these is not to do them unless a profiler tells you this code is a hotspot. Also, you should be wary of writing code that cannot be fully understood by most programmers without checking the spec.

EDIT: As noted in the comments, even though you say you don’t mind if 2 versions of your object get created, that situation is so counter-intuitive that this approach should never be used.