Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1335
| 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> |
> 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 | Next — Previous in thread | Next in thread | Find similar
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