X-Received: by 10.224.189.78 with SMTP id dd14mr274836qab.0.1360207164861; Wed, 06 Feb 2013 19:19:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.49.81.72 with SMTP id y8mr2757816qex.42.1360207164836; Wed, 06 Feb 2013 19:19:24 -0800 (PST) Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!p13no16918032qai.0!news-out.google.com!k2ni8440qap.0!nntp.google.com!p13no16918030qai.0!postnews.google.com!r8g2000vbj.googlegroups.com!not-for-mail Newsgroups: comp.programming.threads Date: Wed, 6 Feb 2013 19:19:24 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: r8g2000vbj.googlegroups.com; posting-host=98.142.246.130; posting-account=8nUMzAoAAACehj29GCRJJmNfA9OMAqRd NNTP-Posting-Host: 98.142.246.130 References: <9b219fb9-0b51-4c06-9398-d1e7ab878f7d@googlegroups.com> <511207c5$0$6565$9b4e6d93@newsspool3.arcor-online.net> <225a96b2-e794-43c7-b82a-64a69c2cb626@hq4g2000vbb.googlegroups.com> <51125d0d$0$6572$9b4e6d93@newsspool3.arcor-online.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17,gzip(gfe) Message-ID: Subject: Re: Double check locking - are release and acquire fences enough for C++ memory model? From: Michael Podolsky Injection-Date: Thu, 07 Feb 2013 03:19:24 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3163 Xref: csiph.com comp.programming.threads:1335 > Additionally I wrote the pseudo code a bit to fast to make it look more > pretty. Usually it looks slightly different and avoids any unnecessary > access to the shared storage. > > =A0 =A0mtx.lock(); =A0 =A0 =A0// wait for mutex, full mem bar no, that one is 'acquire' membar > =A0 =A0{ mtx.release(); // release mutex, full mem bar > =A0 =A0mtx.release(); =A0 // release mutex, full mem bar that one is 'release' membar. "a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations." -- from ANSI C++ Draft. > Maybe there are platforms where Mutex lock/release does not ensure cache > coherence. There should not be, I hope. > But I can's see why release/acquire should /not/ be sufficient in this > cases. So to reply to your original question, I do not see a scenario > where the use of two dependent singletons with double checked > initialization end up in undefined behavior as long as each of the > double checks is implemented correctly. I can only restate my original mail. It contains such an example. If there is now smth unclear in it for you, please detail and I'll try to restate. BTW, as I already said that mutex operations have acquire and release membar semantics, for the same reasons they should not work in a system that does not promise transitive memory visibility. That is, it is either a flow in C++ standard, or flow in my understanding of the topic. I am sure, the 2nd option is here, but I'd like to understand where is my mistake. Michael