thread-safe singleton pattern

  • Thread starter Thread starter John A Grandy
  • Start date Start date
J

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; }
}

}
 
John said:
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; }
}

}
Click to expand...
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.
 
John said:
Is this singleton pattern thread-safe ?
Click to expand...

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
 
Alun said:
Yes, but rather verbose...

What about:

public class Foo
{
public static Foo Instance = new Foo();
private Foo(){}
}
Click to expand...

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

Foo.Instance = null;

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

Foo.Instance = null;
Click to expand...
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.
 
Jeroen said:
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.
Click to expand...

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

Arne
 
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
 
Back
Top