The safe thing to do would be to publish the Test object by writing it into a volatile field.

1. The writer first writes all fields on the Test object, and then writes the reference to the Test object into a volatile field.

2. The reader first reads the reference from a volatile field, and then reads fields of the Test object.

If the object is published via a volatile field, the reader cannot possibly observe the state of the object before it was initialized by the constructor. An alternative solution is to write the object it into a regular field under a lock, and then read it under the same lock.

HOWEVER, in today’s .NET implementation on today’s hardware, I understand that you may be able to get away with removing the volatile modifier on the publication field, even though I would recommend against doing that. For example, Vance Morrison’s article (http://msdn.microsoft.com/en-u.....63715.aspx) on memory models suggests that this lazy initialization pattern is safe:


public class LazyInitClass {
    private static LazyInitClass myValue = null;

    public static LazyInitClass GetValue() {
        if (myValue == null)
            myValue = new LazyInitClass();
        return myValue;
    }
};


I find this particular example very tricky, even trickier than what Vance’s article admits. I understand that the order of writes to myValue and myValue fields is guaranteed by the strong ordering of writes. But, the order of reads has to be enforced using some rule as well. My rough understanding is that x86/x64 will avoid reordering the reads because there is a data dependency between them.

Unfortunately, in this area, even experts disagree on what precisely is and what isn’t guaranteed (example), and so I am not going to claim to know.

I hope this helps. The summary is this: publish the object either via a volatile field or a field protected by a lock, and you’ll be fine. In typical cases, you’ll have some sort of a synchronization between the reader and the writer to pass the object anyways, and that synchronization will be sufficient to insert the appropriate barriers.

Your explanation makes perfect sense. My question was a case of classic overthinking the problem.

Glad I found this blog – it is so hard to find information about these subjects. Following you on twitter now.

Thanks for the great writeup.

Normally, thread-static fields should not have a problem.

A thread-static field has a separate copy of the value for each field. So, a thread cannot possibly see a value written by another thread, simply by design.

For example, if one thread is looping and polling a thread-static field, it is OK to hoist the read out of the loop. If another thread modifies the thread-static field, it will modify its own copy, not the one that the looping thread is checking.

I have a question I can’t seem to get answered; what happens with respect to [ThreadStatic] variables? It is my understanding that static variables marked with [ThreadStatic] could still suffer from the same mutlicore issues that volatile is meant to solve.

I think that demonstrates further that it is (at best) unclear. If any official word on this question does surface, I’d be hugely interested.

@Massimiliano: I think that it is safe to assume that Monitor.Wait and Monitor.Pulse are full barriers. But, I cannot find it somewhere documented explicitly.