Re: Double-Checked Locking pattern issue
"George" <George@discussions.microsoft.com> wrote in message
news:A7F561AA-8AED-4A4C-A87C-D1B604CCEE6C@microsoft.com
For the wellknown Double-Checked Locking pattern,
http://www.ddj.com/184405726?pgno=1
Step 1: Allocate memory to hold a Singleton object.
Step 2: Construct a Singleton object in the allocated memory.
Step 3: Make pInstance point to the allocated memory.
After reading for a couple of times, I still do not understand why
some compiler will exchange step 2 and step 3 code?
It's not the compiler doing it, but the hardware. Modern CPU
architectures may rearrange instructions they are executing. Also, many
architectures feature weak memory models: writes into memory by one CPU
may be seen by another CPU as if performed in different order. E.g.
int x = 0, y = 0;
// thread 1
x = 1;
y = 2;
// thread 2
int yy = y;
int xx = x;
On many modern architectures, it is possible to end up with xx == 0 and
yy == 2. Consider further:
struct Singleton { int x; }
Singleton s; s.x = 0;
Singleton* p = 0;
// thread 1
s.x = 1; // simulating constructor
p = &s;
// thread 2
int xx = (p ? p->x : 42);
// xx == 0 is possible
Again, on modern architectures, it is possible for another thread
(running on another CPU) to observe p != 0 while s.x is still zero.
Modern CPU architectures may exhibit counterintuitive behavior, in the
name of performance. To see just how counterintuitive, watch this:
http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!304.entry
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925