Thread: Double-Check Locking in C++

Originally Posted by Sanches

Really nice paper. Probably one knows how this situation is improved under the new standard, as there is thread support now and they should have a new memory model. See: Foundations of the C++ Concurrency Memory Model, Hans-J. Boehm (2008)

So the memory model changed, but is it already somewhere implemented? Is it improving anything due to Double-Checking?

Don't yet Codeplug make you paranoid. There is no big debate about volatile or memory reordering, at least among people with a clue. I think Codeplug is just trying to cover all the bases.

There's no chance in hell the store to memory will happen after the mutex is unlocked, because the mutex surely uses release semantics when unlocking the synchronization object. If it didn't, it wouldn't be much of a mutex.

Originally Posted by brewbuck

There's no chance in hell the store to memory will happen after the mutex is unlocked, because the mutex surely uses release semantics when unlocking the synchronization object. If it didn't, it wouldn't be much of a mutex.

A release doesn't do anything without an acquire to synchronize with, and the thing about DCL is that the second thread never acquires the mutex, and thus never synchronizes with the release.

Originally Posted by CornedBee

A release doesn't do anything without an acquire to synchronize with, and the thing about DCL is that the second thread never acquires the mutex, and thus never synchronizes with the release.

Doesn't this fix it?

Code:

if(global_ptr == 0){
   mutex->Lock();
   if(global_ptr == 0)
   {
      tmp = new Object();
      writebarrier();
      global_ptr = tmp;
   }
   mutex->Unlock();
}

In other words, it wasn't the second thread's fault, it was the initializing thread's fault for not ensuring the ordering.