Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #1335

Re: Double check locking - are release and acquire fences enough for C++ memory model?

Newsgroups comp.programming.threads
Date 2013-02-06 19:19 -0800
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>
Message-ID <db6fb497-e1bd-4ae2-bea3-ea4d2f6cf23d@r8g2000vbj.googlegroups.com> (permalink)
Subject Re: Double check locking - are release and acquire fences enough for C++ memory model?
From Michael Podolsky <michael.podolsky.69@gmail.com>

Show all headers | View raw


> 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.
>

>    mtx.lock();      // wait for mutex, full mem bar

no, that one is 'acquire' membar

>    { mtx.release(); // release mutex, full mem bar

>    mtx.release();   // 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

Back to comp.programming.threads | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Double check locking - are release and acquire fences enough for C++ memory model? Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-04 23:09 -0800
  Re: Double check locking - are release and acquire fences enough for C++ memory model? Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-02-06 08:35 +0100
    Re: Double check locking - are release and acquire fences enough for C++ memory model? Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-06 04:40 -0800
      Re: Double check locking - are release and acquire fences enough for C++ memory model? Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-02-06 14:39 +0100
        Re: Double check locking - are release and acquire fences enough for C++ memory model? Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-06 19:19 -0800
    Re: Double check locking - are release and acquire fences enough for C++ memory model? Gerhard Fiedler <gelists@gmail.com> - 2013-02-06 11:58 -0200
  Re: Double check locking - are release and acquire fences enough for C++ memory model? Michael Podolsky <michael.podolsky.rrr@gmail.com> - 2013-04-01 12:12 -0700

csiph-web