X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 88.191.16.109
Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!nospam.fr.eu.org!usenet-fr.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!news.bbs-scene.org!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!postnews.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 26 Apr 2011 12:50:05 -0500
From: Pete Becker <pete@versatilecoding.com>
Organization: Roundhouse Consulting, Ltd.
Newsgroups: comp.lang.c++
Date: Tue, 26 Apr 2011 13:50:04 -0400
Message-ID: <2011042613500411162-pete@versatilecodingcom>
References: <78f3178b-efdc-4af5-8f84-7ff6fa995af7@e25g2000prf.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Please disprove this Double-Checked Locking "fix"
User-Agent: Unison/2.1.4
Lines: 61
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-cRP3wyKjtdQDNWcm5stk0PpgTdEWigi2G3kd1aFZSPQiDsGDYA14RGB6DRTxfp/Nv5IdlUCaqKXlpu8!/wBCXLTgOcbXUphnPOltaIn0b+5nFaTOIy+1ns5hweDMV4uOLQHnmyXNkuPtm7OLicouV/XF
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3423
Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:4376

On 2011-04-26 12:58:34 -0400, jl_post@hotmail.com said:

> Hi,
> 
>    Recently I've been reading up on "Double-Checked Locking" in C++
> and how it's often implemented imperfectly.  The Article "C++ and the
> Perils of Double-Checked Locking" by Scott Meyers and Andrei
> Alexandrescu ( http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
> ) provides a good overview of how it's usually done and why it's often
> inadequate.
> 
>    I won't go into details here, but the article states how this code:
> 
> Singleton* Singleton::instance() {
>   if (pInstance == 0) {
>     Lock lock;
>     if (pInstance == 0) {
>       pInstance = new Singleton;
>     }
>   }
>   return pInstance;
> }
> 
> and its variants aren't completely thread safe.
> 

As Leigh said, the issue is not so much compiler optimizations (as 
detailed in the snipped portion of this message) as memory visibility. 
There are systems where writes that occur in one order in the compiled 
code can become visible to other threads in a different order. (read 
the previous sentence several times; it's counterintiutive, but true) 
So even if you can persuade the compiler to generate exactly the code 
that you want, a different thread may see a non-zero value of pinstance 
before it sees the changes made to the thing that the new value of 
pinstance points to. The C++0x solution is:

#include <atomic>
std::atomic<Singleton*> pinstance;

if (pinstance == 0) {
	Lock lock;
	if (pinstance == 0)
		pinstance = new Singleton;
}
return pinstance;

Making pinstance an atomic variable ensures that all writes that 
"happen before" the assignment to pinstance in one thread are seen 
before the result of that assignment is seen in any other thread. In 
essence, it provides a portable wrapper around the memory barrier 
operations in Leigh's suggested solution. (Yes, if you care, his 
solution uses acquire/release semantics, and the solution I've given 
enforces sequential consistency, which is a stronger guarantee; if you 
need to, you can make the atomic variable use acquire/release)

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)