Re: implementation of "Double-Checked Locking" Pattern in C++

From:

"andrew_nuss@yahoo.com" <andrew_nuss@yahoo.com>

Newsgroups:

comp.lang.c++.moderated

Date:

Wed, 25 Apr 2007 00:25:57 CST

Message-ID:

<1177461647.991370.261210@b40g2000prd.googlegroups.com>

What will happen when thread A is suspended just after it finishes
step two and thread B enters the ?Instance()? function?

It will detect that pInstance is not 0 anymore and may exit the
function, returning the address to a section of memory that has not
been initialized. Thus the code that was calling the Instance function
could dereference a Singleton object that has not been constructed
yet! Chaos ?

I've read that you can't do the double-checked locking pattern in Java
and forget why, but it has something to do with synchronized
statements being moved relative to the initial check. Maybe you could
use a temp variable as follows, assuming that the initial check is ok
even on a 64-bit platform, but I would want an expert to tell me that
regardless of how many assembly instructions are needed to do the
assignment to pInstance, that the check whether pInstance==0 is safe:

Singleton* Singleton::Instance() {
    // following expr could fail on 64-bit machine relative to
assignment below???
    if (0 == pInstance) {
        Guard lock(m_mutex);
        if (0 == pInstance) {
            Singleton* temp = new Singleton;
            pInstance = temp;
        }
        return pInstance;
    }
}

I too am interested if the above modification is a correct solution.
Alexandrescu's example uses a volatile modifier for the pInstance
variable but I don't think that is of real use.

Andy

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]