Singleton Implementation Works Fine on 32-bit but not 64-bit

Question

I'm working on an application with a shared object that is accessed via a singleton. It's working fine on 32-bit however on 64-bit it doesn't appear to be locking properly. In the constructor for my object I have code that checks for some config reg keys and prompts the user if they don't exist. On 32 bit I see the prompt only once as expected however on 64 bit the prompt is being displayed multiple times. My code is below:

    private static readonly object padlock = new object();
    private static MyClass _instance = null;
    public static MyClass Instance
    {
        get
        {

            lock (padlock)
            {
                if (_instance == null)
                {
                    _instance = new MyClass();
                }
            }
            return _instance;
        }
    }

Any input is greatly appreciated.

Edited To Include Sample Usage:

    public OtherObject()
    {
        InitializeComponent();

        MyClass.Instance.OtherObjectOrSomething = this;

        this.Load += new System.EventHandler<EventArgs>(OtherObject_Load);
    }

Edited Again This is running inside of an Office AddIn. Thus the bitness is determined by the installation of office. I define a parameterless constructor that is private.

Thanks

Removed Slightly Anonimized Constructor

Answer 1

EDIT: based on some answers and comments, I'll go back to my original answer.

I've done it that way too except I would change the readonly to volatile.

private static volatile object padlock = new object();

The volatile keyword lets the compiler know not to optimize the instruction, which will ensure that the most up to date value is present in the field.

Answer 2

For an excellent discussion of the issues with the various singleton implementation patterns, see http://www.yoda.arachsys.com/csharp/singleton.html (from Jon Skeet).

As it's written, the biggest issue you have is that the compiler is providing a default parameterless constructor which will be public. You should explicitly create a paramaterless contstructor which is private to prevent this. I don't see anything that looks like it would cause an issue based on platform architecture.

Here is the code that I typically use (on both 32- and 64-bit systems):

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new object();

   private Singleton()
   {
      // any code that needs to run to create a valid instance of the object.
   }

   public static Singleton Instance
   {
      get
      {
         if (instance == null)
         {
            lock(syncRoot)
            {
               if (instance == null)
               {
                  instance = new Singleton();
               }
            }
         }

         return instance;
      }
   }
}

Answer 3

It could be something internal to the code in the constructor causing multiple prompts. The view of the registry will be different from a 32-bit process vs. a 64-bit process so they could be responding to the differing external conditions

Answer 4

I put together an implementation here, but it got downvoted twice for some reason :(

Answer 5

Your singleton constrains you to one instance per app domain. Any chance the multiples are getting created in multiple app domains? You might look into that.

Answer 6

In the constructor for my object I have code that checks for some config reg keys and prompts the user if they don't exist.

This is a rather dangerous thing to do in a lazily-loaded static instance. Can you guarantee that the UI thread is always the first one to exercise this code path? I don't know for sure that this is part of your problem, but interacting with the UI inside thread-safe code is rarely a good idea, and I've seen all sorts of weird things happen in differing environments as a result.

Can you move this UI code outside the lazy loading? If this is an Office Add-In then you should have a Startup event to hook, which is guaranteed to only execute once. You don't even need the locking code that way, you can ensure that it's initialized before any other thread ever tries to touch it.