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

Groups > comp.programming.threads > #1330

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

Show all headers | View raw

On Feb 6, 2:35 am, Marcel Müller <news.5.ma...@spamgourmet.org> wrote:
> On 05.02.13 08.09, Michael Podolsky wrote:
>
> > There is very well known 'fix' of double check locking (used particularly in singleton implementation) which uses release memory barrier on (before) the pointer assignment and acquire memory barrier on (after) pointer reading.
>
> I am a bit confused. None of these atomic operations are required if we
> are talking about double check. The idea of double checking is to use an
> ordinary mutex and to provide a fast path for some frequent cases.
> Whether the fast path has a race condition or not is unimportant because
> the mutex will ensure defined behavior.

Let's stop here because if we do not agree about the need of memory
fences in double check locking fast path, the rest is irrelevant.
http://erdani.com/publications/DDJ_Jul_Aug_2004_revised.pdf (chapter
6) gives some argumentation why memory fences are needed, so is
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
(though related to Java).

Particularly, to address your arguments, considering the code without
memory fences (apart implicit in the mutex)

class Singleton
{
public:
static Singleton *instance (void)
{
// First check
if (instance_ == 0)
{
// Ensure serialization (guard
// constructor acquires lock_).
Guard<Mutex> guard (lock_);
// Double check.
if (instance_ == 0)
instance_ = new Singleton;  // line XXX
}
return instance_;
// guard destructor releases lock_.
}
private:
static Mutex lock_;
static Singleton *instance_;
};

on line 'XXX' there is no promise that instance_ variable will be
modified AFTER the Singleton memory is fully constructed, but IF it
happens that instance_ is set to not zero too early, then another
thread may go to the fast path and start to use the singleton before
it is fully constructed. That is why we need some additional release
memory barrier (at least) on the assignment operation on line XXX.

Again, this is classical, I saw very many articles talking about
memory barriers in the double check locking and no article saying it
is all right even without them.

Back to comp.programming.threads | Previous | Next — Previous 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