Memory Model in multithreaded environment: broken double check locking
1. "The double-checked locking is broken" declaration
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Quoted:

Double-Checked Locking:
1. an efficient method for implementing lazy initialization in a multithreaded environment. (Mostly used in Singleton pattern)

Status:
1. In Java, not work reliably in a platform independent way
2. In C++, depends on the memory model of the processor, the reorderings performed by the compiler and the interaction between the compiler and the synchronization library. Explicit memory barriers can be used to make it work in C++, but these barriers are not available in Java.

2. Discussing in memory model in multithreaded C++
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/mmissues.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1876.pdf

Quoted:
problem:
1. C++ standard doesn't mention threads.
2. Threads added via libraries (e.g. pthreads).
3. Compiler mostly unaware of threads.
4. Synchronization calls treated as opaque.

Proposed Solution:
1. Atomic operations library
- load Atomically read the value of the integer.
- store Atomically replace the value of the integer.
- fetch and add Atomically add a value to the integer.
- store with release ordering semantics Atomically replace the value of the integer, and ensure that all prior memory operations executed by this thread become visible to other threads before the update.
- load with acquire ordering semantics Atomically load the value of the integer, and ensure that all later memory operations performed by this thread become visible after the load.

2. Memory model based on sequential consistency to avoid data race
- requires sequential consistency for ordinary variable accesses, but efectively allows reordering of atomic variable accesses when determining the existence of a data race, i.e. it tries to adapt the original solution.

3. Java approach
- sandbox execution of untrusted code
- ensure that no load of a shared pointer can ever result in a pointer to an object that was constructed with a different type. (This requirement will avoid the concurrent read-write confliction to a shared object)


3. Impact
an unavoidable impact on compiler optimization.7 Some currently common compiler optimizations need to be adapted to ensure thread safety. But this also reinforces
the urgency for thread support in C++
- posted by Pop @ 8:31 AM