thread-safe singleton pattern

[John A Grandy]

Is this singleton pattern thread-safe ?


public static class MyClassSingleton
{
private static MyClass _instance;

private static void _establishInstance()
{
if (_instance == null)
{
_instance = new MyClass();
}
}

static MyClassSingleton()
{
_establishInstance();
}

public static MyClass Instance
{
get { return _instance; }
}

}

 

[Jeroen Mostert]

Is this singleton pattern thread-safe ?


public static class MyClassSingleton
{
private static MyClass _instance;

private static void _establishInstance()
{
if (_instance == null)
{
_instance = new MyClass();
}
}

static MyClassSingleton()
{
_establishInstance();
}

public static MyClass Instance
{
get { return _instance; }
}

}

See http://www.yoda.arachsys.com/csharp/singleton.html, which is the most
comprehensive discussion on the subject.

Your version is thread-safe, but it's also unnecessarily complicated. The
check for null is unnecessary as the CLR guarantees that the method will
only execute once.

 

[Alun Harford]

Is this singleton pattern thread-safe ?

Yes, but rather verbose...

What about:

public class Foo
{
public static Foo Instance = new Foo();
private Foo(){}
}

Before you use this, please also note that singletons are there to solve
the problem of being *forced* to have only one instance - for example,
because your class represents a piece of hardware. The use of singletons
makes understanding the program harder due to objects modifying this
global state, and makes testing hard as you can't mock the singleton.

Alun Harford

 

[Arne Vajhøj]

Yes, but rather verbose...

What about:

public class Foo
{
public static Foo Instance = new Foo();
private Foo(){}
}

Private field and public get is more classic and will prevent:

Foo.Instance = null;

Arne

 

[Jeroen Mostert]

Private field and public get is more classic and will prevent:

Foo.Instance = null;

Simply adding "readonly" will do the same for the field.

A more compelling reason to use a property is the advantage (however slight
in this case) of being able to change the implementation of obtaining the
instance.

 

[Arne Vajhøj]

Simply adding "readonly" will do the same for the field.

A more compelling reason to use a property is the advantage (however
slight in this case) of being able to change the implementation of
obtaining the instance.

Or a lazy initialization if proper measures are taken to
maintain thread safeness.

Arne

 

[Josh Einstein]

I also really like the LazyInit<T> structure in Parallel Extensions
(System.Threading.dll). They let you do something like:

private static readonly LazyInit<MyClass> _instance = new
LazyInit<MyClass>(() => new MyClass());

public static MyClass Instance {
get { return _instance.Value }
}

It's a little verbose, but it's nice because the value is only initialized
the moment you actually request it.

It has a couple different synchronization modes. It can ensure the
initializer executes only once, or it can allow multiple initializers to
execute concurrently (storing only the first result), or it can store a
value per thread.

Josh Einstein