Multithreading using Singleton

[Robertlzw]

Folks, I have an impression that the Singleton design pattern should be avoided in multithreaded code. Could you tell me why? Also a friend said he is able to use Singleton in his multithreaded code. I can never figure it out? Any hints, please. Thanks in advance.

Robert

[kbw]

Personally, I think the singleton should not be used. Having said that, if the class' methods are threadsafe, there's no reason why it can't be used in an MT environment.

[firedraco]

If they aren't, you could have the member function that accesses the variable/class be protected by some sort of lock that they would release later (or perhaps pass it into another object).

[jsmith]

The Singleton pattern typically requires on a static variable, initialization of which occurs on the first call to the
function in which the static is declared. However, two threads _could_ call the function simultaneously, leading
to the variable being initialized twice. This is because the current C++ standard does not provide for intrinsic
thread support.

[kempofighter]

There are potentially two problems. First is the call to getInstance thread safe or is the call to getInstance made once in the parent thread in order to eliminate the construction race condition? Secondly, once the construction occurs what type of threading issues exist when multiple users are trying to use the same object?

What are you supposed to do if you have a situation where one object of a particular type must be shared among threads? Somehow you have to ensure that only one object gets created and that all users are sharing the same one and you are going to have threading issue regardless of whether you use the "singleton" pattern or not. As we should all know, the double checked locking pattern isn't reliable so just erase that from your vocabulary immediately. Even if it were reliable it still doesn't solve the second problem of users calling other interface functions on the actual object.

The problem that I have with the singleton is that users will need a dependency to the derived class which might not be what you want. I just don't like to see a bunch of singleton classes and users going directly to them to request the object's reference or pointer. It leads to messy designs in my opinion. However this issue that I have has nothing to do with threading. Using or not using singleton isn't going to solve your threading problems. If we are talking inheritance, you probably want some kind of factory that constructors the concrete objects and returns a pointer to the interface to users. Therefore, I tend to prefer factory patterns that allow objects to be constructed by factories such that only the main function or one other class has a dependency on the most derived factory type. Objects get created during the applications startup and users need to access the pointers. The final question is then, how do users get the factory pointer? You can minimize dependencies all you want but the users have to depend on at least enough things to where they can get access to the factories. Perhaps you can create a class with static functions where the factories can register themselves and users can easily retrieve their pointers without concrete classes exposing themselves to users.

[kempofighter]

One more issue that comes to mind is whether you feel like you have to ensure that only 1 object of some type can ever exist. The reason that many people use singleton is that they feel like they have some requirement to ensure that a singleton can never be created more than once. To do that you have to make all constructors and the assignment operator private and the copy constructor and assignment operator should not be defined. Even if a type should only be created once do you feel that it is a security issue that the constructor is still public (even if only factories are responsible for creating the object)? If that level of security is necessary for objects of this kind then the singleton pattern seems unavoidable. You certainly don't want to use singleton simply to provide convenient access since there are many other ways of accomplishing that. The only reason to use singleton in my opinion is if you have some kind of security requirement where you must prevent a type of object from being constructed more than one time.

But anyway, I don't think its fair to blame singleton for the threading issues. The short comings of the singleton pattern in my opinion lie elsewhere. The other issue is unit testing. Unit testing singleton's tends to be a pain in the butt particularly if there is any branching in the constructor.