The following code is thread-safe as far as I can tell, with the caveat that I am not looking for a singleton pattern (I don’t care if multiple threads get different instances of MyObject as MyObject is immutable. After the potential contention among the concurrent threads that create multiple instances, subsequent threads will all get the same intance).
private static MyObject myObject;
...
public static MyObject GetMyObject()
{
if (myObject == null)
{
myObject = new MyObject(...);
}
return myObject;
}
The following is clearly not thread-safe, since multiple threads could attempt to access the myObject field before it is completely initialized:
private static MyObject myObject;
...
public static MyObject GetMyObject()
{
if (myObject == null)
{
myObject = new MyObject();
myObject.Initialize(...);
}
return myObject;
}
Is the following thread-safe, or is the volatile keyword required on the myObject field? It looks safe as it stands, since the myObject field is not assigned until the object is fully initialized. But I’d be concerned that the JITter might be able to inline the LoadMyObject method and essentially reimplement it as the above code, which isn’t thread safe.
private static MyObject myObject;
...
private static MyObject LoadMyObject()
{
MyObject myObject = new MyObject();
myObject.Initialize(...);
return myObject;
}
public static MyObject GetMyObject()
{
if (myObject == null)
{
myObject = LoadMyObject();
}
return myObject;
}
The background to the above is that I want to refactor some multithreaded code, and replace calls to a constructor by calls to a factory method. And I want to know if doing so can break thread-safety.
EDIT
Just to reiterate, I don’t care if multiple instances of MyObject are created, only that there is no way to access an instance that is not completely initialized. As a concrete example, think of a readonly XmlDocument that is loaded with the contents of a configuration file. I want a static reference to the XmlDocument available in memory to avoid the overhead of loading from disk on every access. But I don’t care if two threads happen to run concurrently and both load the document from disk.
EDIT2
If I understand it correctly, the following statement from the C# Language Specification seems to imply that the JITter won’t reorder my code, so that my last sample should be thread-safe. Am I understanding correctly?
3.10 Execution order
…
Data dependence is preserved within a
thread of execution. That is, the
value of each variable is computed as
if all statements in the thread were
executed in original program order
It’s safe in the sense that you will get a correctly initialised object, but several threads may create objects simultaneously, and a thread might return an object that a different thread just created.
If the compiler inlines the method, it still won’t be the same as the first code. As the reference to the object is kept in a local variable until it’s initialised, it’s still safe.
You can inline the method yourself, there is no need to have the code in a separate method to make it safe:
If you want to prevent that several objects are created by separate threads, you need to use a lock.