Re: double-checked locking for singleton pattern
On May 30, 8:27 pm, Jan Pfeifer <pfei...@stanford.edu> wrote:
On Fri, 30 May 2008 08:50:54 -0600, gpderetta wrote:
Whether you use a lock or a barrier for synchronization, you need to use
the same object on all threads that need to be synchronized.
Sorry, that is true. I failed to detail that in my pseudo-code. Let me
retry it:
Singleton *pInstance = 0;
Mutex mtx1, mtx2;
Singleton* Singleton::instance()
{
if (pInstance == 0) {
Lock lock_1(mtx1);
if (pInstance == 0) {
static Singleton* volatile temp = new Singleton();
{
Lock lock_2(mtx2);
pInstance = temp;
}
}
}
}
In
particular lock_2 (assuming that it is actually locking a mutex, which
is not apparent from your code) is synchronizing with nobody: only one
thread will ever acquire it, so it is useless.
Indeed it is synchronizing with nobody. But is there anyway for the
compiler to know that ? How can it know that no other thread is going to
synchronize on mtx2 ?
Whole program analysis?
Well ... but maybe i'm back to the assumption that i can beat the
compiler into not optimizing something, which as A.Alexandrescu&S.Meyers
tries to discourage us from.
Although i would be surprised if today's compiler would optimize out a
lock like above
compilers have surprised me many times.
-- it has to understand about all other possible threads,
and mtx2 being global, understand at link time that it is being only
locked in one place -- that means the linker has to know about the
semantics of locking.
If the linker can do link time optimizations, it certainly must. And
probably many do. For example I know for sure that there are Java
compilers that can remove useless locks. I wouldn't be surprised if C+
+ compilers did the same.
Also, AFAIK, nothing in your code, assuming a relaxed memory model,
guarantees that, if pinstance is != 0, it will actually point to a valid
object (and, no, I'm not talking about the fact you didn't zero
initialize it).
the idea is that lock_2(mtx2) works as a barrier: that is the compiler
cannot move the assignment "pInstance = temp" across that.
If that is true, pInstance will only be != 0 after the object it points
to is properly constructed.
This might fool some compilers which do not do whole program
compilation; It certainly won't fool the cpu, which is free to load
the pointed-to value before loading the pointer (yes, some cpus are
actually capable of doing that). I.e. you have to prevent reordering
(by the compiler or cpu), not only at the store, but also at the load.
Otherwise many other things would break: imagine if the compiler starts
moving assignments on a shared memory structured before it actually
acquires the lock !?
As long as you use locks correctly AND your compiler understands them,
nothing will break.
--
Giovanni P. Deretta
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]