know you answer this my question. I ask you, because it is related to this article. Can you help me here please:
http://social.msdn.microsoft.c.....f41a9f84d1

This topic seems particular useful for out-of-process services that are intended to provide asynchronous handling of multiple tasks (such as for a high-traffic website that relies on a SOA to display aggregated data).

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.