C++单例模式的困境

写在之前

这篇文章应该是写在两年前，一直在自己的one note里面。当时为了练习英文写作就全篇用英语写的。主要内容来自Scott Meyer和Andrei Alexandrescu的那篇著名的论文。再加了一些关于单例模式的可测试性的讨论。

Introduction

To make Singleton thread safe is extremely difficult in C++. Double-Checked Locking is a good way to implement thread safe Singleton. However, DCLP has its own problems that it can not be guaranteed to be thread safe in any circumstances. The problems come from two corners which are single-processor architecture machine and multi-processor architecture machine. I will recap the problems in the following paragraphs, please refer to DLCP to get the most detailed descriptions.
Additionally I appended some other discussion relating to testability and replacement of Singleton.

Single-Processor Architecture Machine

Code optimization is really evil in Singleton Pattern. Considering the following typical singleton implementation code snippet:

__instance = new Singleton();

The above codes will be translated into 2 statements which will be executed in 3 steps:

__instance = //step3
operator new( sizeof(Singleton)); //step1
new(__instance) Singleton;//step2

In general, programmers want the codes executed in order of step1, step2, step3. However, this is not guaranteed by C++ standard. Therefore, for some compliers the actual execution order might be step1, step3, step2. In this case, if the constructor throws exceptions, __instance will be left with an invalid pointer. Beside this, taking multi-threading into account, if thread A suspended at step3, at which moment the __instance is assigned to pointer to a uninitialized memory block, thread B is woke up and dereference __instance which will cause undefined behavior. The root cause of such a problem is that the program execution sequence is not guaranteed by C++ standard. If we can impose some constraints on the execution sequence, this problem might be solved. A natural solution is provided like this:

Singleton* _temp = new Singletion();
__instance = _temp;

We explicitly make the assignment to __instance the last statement so that we can make sure the __instance is not changed before the Singleton object is completely constructed. It seems a perfect solution. But if we take code optimization into account, this solution becomes useless because the complier might optimized the above codes into a simple one-line code:

__instance = new Singleton();

Oops, we go back to the beginning. This is why we say at the very beginning that the code optimization is evil in this scenario.

The final solution involves using volatile keyword.

Singleton* Singleton::instance()
{
    if( __instance == NULL )
    {
        Lock   _lock;
       if( __instance == NULL )
       {
           Singleton* volatile _temp =
           static_cast<volatile Singleton*>(operator new(sizeof(Singleton)));
           __instance = _temp;
       }

     }
}

volatile will prevent compilers from optimizing the codes. You might think this will solve the problem once and for all. Unfortunately, this solution is imperfect. Put the above codes in multi-threading environment, it will still cause the problems we have described in this article.

First, the C++ standard assumes an abstract machine which is single-threaded. In this case, volatile is only guaranteed to work under single-threaded environment. This problem is inherent in C++ language and can not be solved without support from C++ language.

Second, a volatile object is guaranteed to be volatile qualified only if the object is completely constructed. This means that before the constructor of Singleton runs to completion, _temp is not volatile qualified. This brings us to the beginning again that the compiler might re-order the execution sequence. This problem can be solved by declaring every variable in constructor to be volatile.

??What about c++ 11. Any changes on abstract machine??

Multi-processor Architecture Machine

In multi-processor architecture machine there is a problem called "cache coherency problem". Every processor has its own memory cache. Variables are first updated to the cache, then to the shared memory where the variables can be accessed by other processors. The inconsistency between the cache and the shared memory is called "cache coherency problem". The ordering of updating variables to shared memory might be different to the ordering specified in the source code( it is highly likely to update variables by ascending order of variables' address due to efficiency). This will cause the same problem addressed in the single-processor architecture machine.

Image that the step3 is updated to the shared memory prior to step2, which will cause another processor accessing the uninitialized __instance thus might crash the program. To solve this problem, different machines provide different tools which are called by 1 memory barrier in general.

Conclusion for Implementation of Singleton Pattern

It is impossible to implement a complete thread-safe Singleton Pattern in C++. The root cause of such a inability is that 1) in single processor architecture the C++ standard does not guarantee the execution order of instructions; 2) in multi-process architecture the ordering of updating variables to shared memory is not guaranteed either.

There are some advises concluded by DLCP:

Time slice based single processor parallelism is not the same as the true parallelism across multi-processor.
DCLP is not intrinsically tied to Singleton Pattern. Avoid to use DCLP to implement Singleton Pattern. To cache the pointer to minimize the synchronization cost.
Avoid using lazy instantiation. Use eager instantiation instead. All programs start with a single thread where we can put Singleton instantiation codes.

Singleton and DI

Someone suggests to use DI instead of Singleton objects so that we can gain more testability from the change. To illustrate the problem, imagine that we have a singleton class declared as below:

class Singleton
{
public:
    static Singleton* GetInstance(void);
    static Singleton* __instance;
}

And also imagine the scenario that use the Singleton object:

void test_singleton(void)
{
    Singleton::GetInstance()->DoSomething();
    //other stuffs
}

Now try to write a test for test_singleton. Uh, don’t know how to proceed? Some people believe that Singleton object is no more than a global object and thus it is anti-pattern. I believe so, but Singleton is really convenient to use. By using DI we can solve the testing problem. In an extreme scenario, if there were 1000 places that uses Singleton objects, we have to pass Singleton object references 1000 times, which is awkward.

There is a simple way to solve the testing problem for Singleton. Just use macro and condition compilation. However, this solution is invasive.

Singleton and Monostate

Singleton promise to have only one instance existing in the whole life. However, Monostate promise to have only one state in the whole life but as many instances as you wish. Please refer to Agile Principles to get details.

Written with StackEdit.