Some Ideas about the singleton Mode Implemented by DCLP, some ideas about dclp

Some Ideas about the singleton Mode Implemented by DCLP, some ideas about dclp
Some Ideas about the singleton Mode Implemented by DCLP

I have written a singleton article (http://www.cnblogs.com/mkdym/p/4908644.html) before, but now I have some ideas and don't want to update it in the original article, so I just open one.

When reading some books or articles about the singleton mode, we always talk about DCLP, and come to the conclusion that DCLP is unreliable and cannot be used to implement Singleton. That is, the following is an error:

class SingletonAA{public:    static SingletonAA& get_instance_ref()    {        if (NULL == p_) // 1st check        {            scoped_lock lock;            if (NULL == p_) // 2nd check            {                p_ = new SingletonAA();            }        }        return *p_;    }private:    SingletonAA()    {        //...    }    ~SingletonAA()    {        //...    }private:    static SingletonAA *p_;};SingletonAA *SingletonAA::p_ = NULL;

Because the new sentence is not atomic, it is divided into three steps, and the order is not necessarily, this order will affect the results of the first check. Then they discussed volatile keywords and out-of-order optimization, and concluded that this keyword cannot make DCLP correct or easily make DCLP correct.

However, when talking about this problem, the premise is that the pointer of the single-instance object is used to determine the condition, which is the cause: the creation of a singleton object and the judgment of a singleton object are read and write to the same element, and the "write" is too complicated!

So I don't need to use a single-instance object for judgment. Isn't that enough? As follows:

class SingletonAA{public:    static SingletonAA& get_instance_ref()    {        if (!init_flag_) // 1st check        {            scoped_lock lock;            if (!init_flag_) // 2nd check            {                p_ = new SingletonAA();                init_flag_ = true;            }        }        return *p_;    }private:    //...private:    static SingletonAA *p_;    static bool volatile init_flag_;};SingletonAA *SingletonAA::p_ = NULL;bool volatile SingletonAA::init_flag_ = false;

I use a bool flag. The bool variable is a byte in vc, and only one instruction is required for operations, which is atomic. It is declared as volatile to ensure that the compiler does not optimize it.

Press myInaccurateKnowledge, the compiler or CPU may

p_ = new SingletonAA();

And

init_flag_ = true;

The order of the two sentences is adjusted because they are not correlated, and this will lead to errors. Then I create an association:

init_flag_ = p_ ? true : false;

The assignment of init_flag _ depends on the creation of the object,According to my understandingIn this case, both the compiler and CPU should make the flag statement after the object creation statement, so there is no error.

If the compiler assumes that p _ is not 0 after new execution, it can optimize the assignment of init_flag. So will this happen? Does the compiler think so?

 

Need Help

Need Help

Need Help

(Weight 3)

 

Because I want to get everyone's attention, I chose "Publish to blog garden Homepage" as a shameful option. If it does not appear on the homepage at the end, I will delete this sentence, without losing my face.