.NET interview question - when is a singleton not a singleton?

I've read some posts lately with questions people use to ask or have been asked during a job interview, so I wanted to post a tricky question too.

I've talked about singletons in the past, and what we use to think is that a classic singleton class has to be unique into a specific AppDomain. Let's take this simple implementation of the singleton pattern, which is thread safe, too: [edit: made the class sealed to avoid confusion]

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();

// Private constructor to prevent external instantiation
private Singleton()
{}

public static Singleton Instance
{
get { return instance; }
}
}

There's at least one situation where you can find yourself having multiple instances of the singleton class in the same AppDomain, can you tell when?

kick it on DotNetKicks.com

Published 30 April 2007 01:14 AM by simoneb
Filed under:

Comments

# DotNetKicks.com said on 29 April, 2007 05:30 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# mcgurk said on 30 April, 2007 10:06 AM
Ya got me. If you were instantiating it lazily, there is a remote possibility that the variable is read from the register rather than memory which can result in multiple instantiation... However, your singleton is being created by the class constructor. The class constructor is guaranteed thread safe by the CLR, so it doesn't seem possible that it can result in two singletons being created. I'm not 100% sure that extending this class won't result in multiple singletons being created. In this case, I'd seal the Singleton class unless I specifically wanted someone to be able to extend it.
# simoneb said on 30 April, 2007 10:28 AM

Yeah making it sealed wold avoid confusion. What I was really thinking about is a couple of ways to bypass the OO principles and do something that apparently wouldn't be allowed, like instantiating this class twice... Anymore ideas? ;)

# mosessaur said on 30 April, 2007 12:42 PM

one of the cases is when your singleton class is marked as serializable! We had this situation once, we were storing [Serializing] the singleton instance in ViewState and when post back we read it from ViewState again, in this case we have 2 deferent instances, on already loaded in the memory and the other is loaded from ViewState!

# simoneb said on 30 April, 2007 04:09 PM

Right mosseaur. That's it. I can think of at least another way of having two instances of this class, tough.

Just to ask, how did you solve your issue with the singleton in the ViewState? This particular issue can be fixed in an elegant way as far as I know, I guess I'll post about it in a few days.

# mosessaur said on 30 April, 2007 07:06 PM

I'm waiting to read your resolution to this issue. and I'll ask the guys here how exactly did they overcome this issue, but I think we avoid it but not resolve it! I'm not sure I'll check and get back to you.

I was discussing this with one of my friends, he reminded me of the serialization issue with singletons, also he came up with something else but not sure if this will result in the same issue, he said what if we loaded the class dynamicly using deferent evidence etc.. does this result in the same issue! for example loading same assembly twice, one time from local machine and another time from a remote machine!! I think this should result in the same issue as the assembly will be loaded using deferent evidence.

Really this is wonderful question Simon

# simoneb said on 30 April, 2007 07:20 PM

Well, this implementation of the singleton is supposed to be a singleton in the same AppDomain, so having another instance of the class in another machine - and thus another AppDomain - doesn't count.

However, the other way I can think of is by instantiating the class via reflection, some old tricks btw...

I will post about the serialization workaround soon ;)

# SimoneB's Blog said on 03 May, 2007 08:18 PM

Some days ago I wrote about the issue of having multiple instances of a singleton class in the same AppDomain.

# Rick Strahl said on 04 May, 2007 04:46 AM
Interesting problem, but I wonder, what kind of singleton would you ever want to serialize? I mean the whole point of the singleton pattern is that there's only a single instance available - if you start persisting this object you're kind of going past the whole idea in the first place. Still an interesting thing to think about - I couldn't figure it out when I looked at it first <s>...
# simoneb said on 04 May, 2007 08:23 AM

Actually I never ran across this issue myself, I was just thinking "philosophically" about singletons, since it's something I've been talking about pretty often lately ;).

However, as Mosseaur reported a few comments above yours, they had to persist a singleton to the ViewState, and restoring it from there ended up with having a duplicate instance.

Although I can't think of another practical situation where you'd need to serialize a singleton I guess it's something the .NET framework developers considered, since they created some classes and interfaces explicitly for this purpose. I talk about them is my last post.

# Lexapro. said on 04 August, 2008 05:19 PM

Alcohol and lexapro. Lexapro. Lexapro and alcohol. Lexapro generic. Gain weight on lexapro.

This site

Search

Go

This Blog

News

Syndication

Sponsors

  • MaximumASP