Re: Thread-Safe Singleton - C# Discussion Boards

8-Dec-03 4:18

This is the code I have always used for a singleton.

public sealed class Singleton
{

private Singleton(){}
public static readonly Singleton Instance = new Singleton();

}

I am just getting into multithreading. I have read conflicting opinions on whether or not the code above is thread-safe?

Robert Zurer
robert@zurer.com

Heath Stewart8-Dec-03 5:07

8-Dec-03 5:07

statics are initialized with the Type, but the above code won't get you a singleton. The code below is oft-used and recommended by Microsoft for the .NET Framework:

public sealed class Singleton
{
  private static Singleton instance;
 
  private Singleton() {}
  // Makes sure that only one instance exists.
  private static Singleton Instance
  {
    get
    {
      // Thread-safe initialization.
      if (instance == null)
        lock (typeof(Singleton))
          if (instance == null)
            instance = new Singleton();
      return instance;
    }
  }
  private void doSomething()
  {
    Console.WriteLine("Something done.");
  }
  public static void DoSomething()
  {
    Instance.doSomething();
  }
}

Notice how the public methods are static? In most cases, this is what you want because you control what the caller can do. The Instance property is a thread-safe initializer that makes sure that only one instance is created. Your public static methods use that property (which will initialize the class instance if necessary) to call private instance methods or use private instance properties or fields. That is a singleton.

Keep in mind that the methods themselves are not thread-safe this way, though. To do that, you'll either want to use the lock keyword (on a static object, like the typeof(Singleton) I used, or this for instance methods / property accessors).

Now, you can accomplish this another way by using a ContextBoundObject where you can intercept calls but to the caller - it's just creating a new instance (where you return an existing instance). This gets into remoting issues which are more advanced, so you should probably try this out first. It's by far easier and accomplishes the same task.

Paul Evans8-Dec-03 6:37

Paul Evans

8-Dec-03 6:37

good call! Like that.

You may want to look at the lock hint pattern, so it doesn't have to do the mutex lock each time.

/**********************************
Paul Evans, Dorset, UK.
Personal Homepage "EnjoySoftware" @
http://www.enjoysoftware.co.uk/
**********************************/

Heath Stewart8-Dec-03 6:56

8-Dec-03 6:56

Not familiar with that, but in this case the lock is not performed each time. Once the instance is non-null, the rest of the condition block isn't executed.

Paul Evans8-Dec-03 7:05

Paul Evans

8-Dec-03 7:05

you kind of did it, but without the boolean flag.

It's name is the "The Double-Checked Locking Pattern"

Example implementation here:
http://www.cuj.com/documents/s=8047/cuj9910ringle/

It comes from this academic paper (although the link is dead you can find it if you hunt about a bit):
[5] Douglas Schmidt and Tim Harrison. "Double-Checked Locking: An Optimization Pattern for Efficiently Initializing and Accessing Thread-safe Objects," http://www.cs.wustl.edu/~schmidt/DC-Locking.ps.gz

/**********************************
Paul Evans, Dorset, UK.
Personal Homepage "EnjoySoftware" @
http://www.enjoysoftware.co.uk/
**********************************/

Heath Stewart8-Dec-03 7:12

8-Dec-03 7:12

I did do the double-checked locking mechanism! Look at my code again:

if (instance == null)
  lock (typeof(Singleton))
    if (instance == null)
      instance = new Singleton();

Looks like double-checked locking to me, and was called such (couldn't remember what the "technical" term) in a Microsoft article published in the 1.0 beta days.

Paul Evans8-Dec-03 7:20

Paul Evans

8-Dec-03 7:20

Indeed, as I said, you did it without the boolean flag. Kudos.

/**********************************
Paul Evans, Dorset, UK.
Personal Homepage "EnjoySoftware" @
http://www.enjoysoftware.co.uk/
**********************************/

Heath Stewart8-Dec-03 10:08

8-Dec-03 10:08

Sorry, I misunderstood one of your posts (well, maybe). As far as a boolean flag goes, though, the way I used a conditional would result in few instructions and field members. Having a separate field just to remember this would increase the size of the Type, and having to set that in addition to instantiating the singleton class is yet a few more instructions:

ldarg.0
ldc.i4.1
stfld Singleton.initialized

bzurer8-Dec-03 7:07

8-Dec-03 7:07

You mention that the methods themselves are not thread-safe. Do you mean that the method

public static void DoSomething()  <br />
{    <br />
    Instance.doSomething();  <br />
}

Should be

public static void DoSomething()  <br />
{    <br />
    lock (typeof(Singleton))<br />
    Instance.doSomething();  <br />
}

even though Instance itself is protected by a lock?

Heath Stewart8-Dec-03 7:10

8-Dec-03 7:10

The instance is not protected by a lock - the initialization of the Singleton was protected by a lock, but that was just to make sure that only one instance of the Singleton class was initialized. See the discussion Paul and I are having on this thread for more info.

Also, it is not necessary to lock every static method - only if you need to synchronize access to a resource. For doing something as simple as a calculation that doesn't use instance resources, you don't need to, like:

public static int Add(int a, int b)
{
  return a + b;
}

bzurer8-Dec-03 7:56

8-Dec-03 7:56

In this case, my Singleton will be used to synchronize access to a centralized Hashtable which holds the 'clean' or saved values of properties of objects while the actual objects are being validated, persisted and then finally updated if all goes well. After the update succeeds the values are removed from the hash table.

The aim is to allow multiple threads to be able to have read consistency while a write is going on. I want to accomplish this by deriving all my business from ContextBoundObject.All calls to set methods would be intercepted and the existing values added to this Hashtable(keyed to a global object id).

When another thread wants to read, the get method is intercepted, and, in SyncProcessMessage, the MessageSink checks for an entry in this Hashtable, if one is found, the value of the property is taken from the Hashtable and passed to the caller, otherwise it passes the IMessage unaltered.

I assume this Hashtable qualifies as a resource.

But this brings up another two questions.

1 - By using ContextBoundObject am I in some way automatically serializing access? and if not
2 - Must I place a lock within SyncProcessMessage?

Heath Stewart8-Dec-03 9:14

8-Dec-03 9:14

I don't know if you want to mess with a ContextBoundObject in this case. It's a lot of overkill. For instance, you want the value to always be available whether or not it exists first (or something like that). Use myHashtable[key] = value. If the key exists, the value is changed. If it doesn't exist, the key is added and the value is still set. Using a ContextBoundObject also means that the objects you're passing around have to be serializable and this mechanism is a little slower (as you have probably figured out) that direct calls.

As far as threading the Hashtable goes, you should actually lock against Hashtable.SyncRoot, or use the synchronized Hashtable returned from the static method Hashtable.Synchronized(myHashtable).

Zhang Ye Fan8-Dec-03 7:33

Zhang Ye Fan

8-Dec-03 7:33

By why do we need the "instance" in a singleton at all? Making the methods static seems to be enough:

<br />
public sealed class SingletonNoInstance<br />
{<br />
    private static Object m_objInit = new InitObj();<br />
<br />
    private static Object InitObj()<br />
    {<br />
        // do intialization here<br />
        // ...<br />
        return new Object();   <br />
    }<br />
  <br />
    public static void ThreadSafeDoSomething()  <br />
    {    <br />
        lock(typeof(SingletonNoInstance))<br />
        {<br />
            // do something here<br />
            // ...<br />
        }<br />
    }<br />
}<br />

The private member m_objInit and method InitObj() can be removed if no initialization of the class is required.

Heath Stewart8-Dec-03 9:08

8-Dec-03 9:08

There's a difference between singletons and a class with static methods. If you just have simple static methods (like the System.Math class), you don't need to construct a singleton. Singletons are useful when you want lots of different callers to use the same resource without having multiple instances of that resource (or the class that has that resource). For instance, all throughout the .NET BCL (and our application I architected), most classes in an assembly use a internal singleton that has a single instance of a ResourceManager that contains strings (and other resources at times) for all classes to use (like common exception messages or property categories and descriptions). It would be horribly inefficient to have an instance of this ResourceManager for each class (and who knows how many instances of each class?!), so they use a singleton with a single instance of the ResourceManager.

There are many other reasons for singletons (if you know anything about remoting, there's some good examples for that, too). This is just a common example I think of because I use it a lot and it is far more efficient to do it this way that for each instance of a class to have it's own - especially when you're sharing string resources amongst other classes.

bzurer11-Dec-03 3:31

11-Dec-03 3:31

In doing further reading, I came upon Jon Skeet's excellent article.

http://www.yoda.arachsys.com/csharp/singleton.html

Unless I'm reading him incorrectly, the fourth version of the Singleton he presents is the same code I have been using.

public sealed class Singleton<br />
{<br />
        private Singleton(){}<br />
        public static readonly Singleton Instance = new Singleton();<br />
}

He calls it "thread-safe without using locks". What I understand from his article is that this thread-safety is due to the way the Framework handles static type initializers. Have I missed something?

Heath Stewart11-Dec-03 4:30

11-Dec-03 4:30

You'll also notice he calls it "lazy". Besides, you still need to add the static constructor so the correct IL is generated.

The biggest difference between this and the way we were previously talking about (double-checked locking) is that static constructors as executed at most once per application domain. This means that your Singleton will be a different singleton in each AppDomain your application uses (in a distributed app that uses Remoting or Web Services, there is at least two AppDomain, and even a your process can create additional AppDomain on the same machine).

One important thing to keep in mind - the performance penalties for the double-checked locking are negligible - it only locks once and the first conditional statement is a one-line instruction in IL and is extremely quick. This is the proper way to do it. Lazy programming leads to bugs and holes.

bzurer11-Dec-03 4:56

11-Dec-03 4:56

Very cool.

The clouds have parted.

I will not be traversing AppDomains but I will be accessing the singleton from a ServerContextSink.

I don't know whether that would also defeat the thread-safety of the first method, but as you say the performance hit for the lock is negligible (certainly negligible compared to the 1000% hit I seem to be taking instantiating ContextBoundObject), I will definite use double-checked locking.

Robert Zurer
robert@zurer.com

about setup projects

Mauricio Ritter8-Dec-03 3:50

Mauricio Ritter

8-Dec-03 3:50

Hi guys...

I've created a setup project using VS.NET. It works fine, change some registry keys, create my database (using my installer class), creates some IIS virtuals dirs. The problem is that I need to force the machine to reboot after the installation has been completed. Does anyone know how to to this ? Is there any parameter I can change in my installer class to do this ?

thanks in advance

Mauricio Ritter - Brazil
Sonorking now: 100.13560 MRitter

English is not my native language so, if you find any spelling erros in my posts, please let me know.

Re: about setup projects

Heath Stewart8-Dec-03 3:55

8-Dec-03 3:55

I just covered this a day or two ago (searching first is always a good idea). Set the REBOOT property (must be all upper-case) to Force. See the Windows Installer SDK for more information.

Since VS.NET's setup projects suck, you'll have to download Orca (part of the Windows Installer SDK, which is part of the Platform SDK) and make the changes post-build. Just open the MSI package, find the Properties table, and add said property. You could also do this using a custom action, but it's quite a bit of overhead for a such a simple task.

Re: about setup projects

Mauricio Ritter8-Dec-03 4:20

Mauricio Ritter

8-Dec-03 4:20

Heath Stewart wrote:
You could also do this using a custom action, but it's quite a bit of overhead for a such a simple task.

Actually I already have a installer class with custom actions in my setup project, it would be easier to insert the property there, I just don't know where to insert it. I tryed the Context.Parameters collection but it didn't work. Any ideias ?

Mauricio Ritter - Brazil
Sonorking now: 100.13560 MRitter

English is not my native language so, if you find any spelling erros in my posts, please let me know.

Re: about setup projects

Heath Stewart8-Dec-03 4:52

8-Dec-03 4:52

You can't, actually. .NET Installer classes have nothing to do with Windows Installer, Windows Installer is just able to run them as custom installer actions. I was talking about native custom actions that you'd have to write in C/C++ (with C-style functions).

The easiest way is to install Orca and edit the MSI yourself. Just go to mdsn.microsoft.com and go to downloads. Click Platform SDK but only install the Windows Installer SDK. It will install only a few required components from the PSDK itself. Legally, I cannot just send you the installer for Orca but it is an invaluable tool and is worth the download if you're messing with installer packages.

About Collections?

E#8-Dec-03 3:29

8-Dec-03 3:29

C++ has its STL for doing stuff like linked lists etc.

What about .NET? I need data structures to dynamically manage lots of different objects. Are the Collections fast enough?

Which types of what are found in .NET are suitable for real-time applications that need to create and destroy lots and lots of objects very fast? Smile | :)

at the same time the garbage collector also should not interfere too much. Hopefully it will be unnoticable.

Any suggestions from your experience? What should I prefer.

Re: About Collections?

E#8-Dec-03 3:31

8-Dec-03 3:31

Well an example could be: performance of stl::list vs. .NET collections?
Application: real-time simulator

Thank you!

Re: About Collections?

Heath Stewart8-Dec-03 3:52