Re: Please disprove this Double-Checked Locking "fix"
On May 1, 9:49 pm, Leigh Johnston <le...@i42.co.uk> wrote:
On 30/04/2011 23:54, James Kanze wrote:
On Apr 26, 5:58 pm, jl_p...@hotmail.com wrote:
Recently I've been reading up on "Double-Checked Locking" in
C++ and how it's often implemented imperfectly.
You mean, how it is impossible to implement in standard C++
(03).
The Article "C++ and the Perils of Double-Checked Locking" by
Scott Meyers and Andrei Alexandrescu
(http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf)
provides a good overview of how it's usually done and why it's
often inadequate.
The standard solution for implementing a singleton works just
fine:
Singleton* Singleton::instance()
{
ScopedLock lock(mutex);
if ( pInstance == NULL )
pInstance = new Singleton;
return pInstance;
}
How does this prevent CPU reordering of stores to the
pInstance pointer and the object pInstance points to?
Compiler magic:-).
Presumably, somewhere in the constructor of ScopedLock, you end
up calling pthread_mutex_lock, or something similar. And if the
compiler is Posix compliant, it knows that it cannot move code
accross a call to pthread_mutex_lock. (And of course, the code
in pthread_mutx_lock contains the necessary machine instructions
to ensure that the hardware respects the order. Posix requires
it.) (Replace Posix with Windows, and posix_mutex_lock with the
corresponding Windows function, if that's your platform.)
Of course, if the compiler doesn't support multithreading (or
you didn't specify the options it requires for it to support
multithreading), then there is no solution; you cant use
multithreading, period.
--
James Kanze