Singleton: Ammendment 1

An excellent issue was raised by Farzad in his comment to my previous post (Singleton) regarding the fact that when you have a multi-instanced singleton and the singleton is going to decide based on the current thread what object to return it's better to store it in the thread using SetData & GetData.
I absolutely agree with Farzad since this will save us from the hassel of clean up issues. Consider the example of the multi-instanced connection manager:

public class ConnectionManager
{
 /* ConnectionManager implementation */

 //Singleton logic:
 private ConnectionManager() { }

 private static Dictionary _instances = new Dictionary();

 public static ConnectionManager Instance
 {
  get
  {
   lock (_instances)
   {
    if (_instances.ContainsKey(System.Threading.Thread.CurrentThread) == false)
     _instances.Add(System.Threading.Thread.CurrentThread,new ConnectionManager());
   }
   return _instances[System.Threading.Thread.CurrentThread];
  }
 }
}

One problem with the above code that you would have to resolve is what happens when a thread is terminated? The singleton will still contain a reference to the ConnectionManager associated with the thread and over time this could cause a memory leak. Now in my previous post this was only supposed to be an example, but in real life you should take this stuff into account.
There are multiple ways to solve this. In some systems you wouldn't have a problem because a very limited number of threads will be created and maintained throughout the lifetime of the system. You could also use weak references that will automatically get cleaned up when the garbage collector is doing a round of clean up.
But a very elegant solution would be using the Thread.SetData & GetData methods. So the result would look like this:

public class ConnectionManager
{
 /* ConnectionManager implementation */

 //Singleton logic:
 private ConnectionManager() { }

 public static ConnectionManager Instance
 {
  get
  {
   if (Thread.GetData(Thread.GetNamedDataSlot("ConnectionManager")) == null)
    Thread.SetData(Thread.GetNamedDataSlot("ConnectionManager"), new ConnectionManager());

   return (ConnectionManager)System.Threading.Thread.GetData(Thread.GetNamedDataSlot("ConnectionManager"));
  }
 }
}

As can be seen in the above code we aren't using an explicit data structure to store our ConnectionManager objects but we are using a place that the thread will provide for storing data specific to this thread. The other interesting bit about the above code is there is no need for locking due to the fact that the SetData & GetData function are operating on the current thread's data and there is no way two threads can access one thread's data at the same time :)