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

Groups > comp.programming.threads > #1329

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

Show all headers | View raw

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.

In my opinion using acquire semantics in the fast path is contrary to 
the idea of a double check. In fact it makes the fast path a slow path, 
because of the synchronized read instruction. Keep in mind that most 
fast mutex implementations will take almost the same time to acquire the 
mutex than the synchronized read - at least in the case where the fast 
path is an option.
Additionally using release semantics to store the pointer is superfluous 
because this operation need to be done with protection of the mutex. And 
releasing a mutex is always a full memory barrier.

> Now, correct me if I am wrong (I may very well be), but there is no general promise that causality is supported  by any system, at least as for C++ memory model, the relation 'happens-before' is not guaranteed to be transitive.

What do you mean with 'transitive' here?

> This may mean that if Thread T1 constructs singleton X, Thread T2 'acquires' singleton X, then constructs singleton Y and STORES inside it a pointer 'p' to singleton X, then Thread T3 which acquires singleton Y cannot use a pointer 'p' not directly and not via the methods of singleton Y because the singleton X may be still not visible for T3.

You should provide a short code example to let us know about what kind 
of implementation you are talking. At least your description fits in no 
way to the double checked singletons I know so far.

static T* ptr = NULL;
static Mutex mtx;

T* get_singleton_T()
{ if (!ptr)          // First check, race condition accepted
   { mtx.lock();      // wait for mutex, full mem bar
     if (!ptr)        // the double check
       ptr = new T(); // create singleton
     mtx.release();   // release mutex, full mem bar
   }
   return ptr;
}

With this code a dependency of singleton X to singleton Y is no problem 
at all, since the getter will never return incomplete objects.

However, if you /modify/ one of the singletons /after/ construction, the 
singleton object itself has to be thread safe. This has nothing to do 
with the double check idiom.

> I am currently unsure of correct implementation of previous scenario (if it really needs to be fixed). We could use memory_order_seq_cst atomic operations on pointers instead of non-sequential memory fences, but I am unsure whether it will make non-atomic stores and loads related to the creation and reading of singletons memory behave in some better 'transitive' way.

Please provide a code example of your scenario.

> Thanks for your comments and corrections, if any.


Marcel

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