Re: Please disprove this Double-Checked Locking "fix"
Leigh Johnston wrote:
On 01/05/2011 22:44, Leigh Johnston wrote:
On 01/05/2011 22:26, Pavel wrote:
Leigh Johnston 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?
Any system-dependent mutex has to behave like a double-side memory
barrier (it's a follow-up from the mutual exclusion requirement).
I didn't realize this was guaranteed for all systems...
The ellipsis was an indication that I find your claim that all mutex
implementations include memory barriers slightly dubious. :) From
Wikipedia:
"These primitives (mutexes) are *usually* implemented with the memory
barriers required to provide the expected memory visibility semantics.
In such environments explicit use of memory barriers is not *generally*
necessary."
I guess a mutex implementation that didn't include memory barriers on a
system where memory barriers are needed would not be very useful.
Yes, that's what I meant. Wikipedia is a great resource to find an explanation
of a concept but it does not have to tie all ends together with the strictness
of a specification. In our case, the article on Mutual Exclusion says:
"Mutual exclusion .. algorithms are used in concurrent programming to avoid the
simultaneous use of a common resource, such as a global variable, by pieces of
computer code called critical sections. A critical section is a piece of code in
which a process or thread accesses a common resource".
In our case, we want mutual exclusion for threads and our "common resource" is
memory containing pInstance. A mutex that in fact does *not* allow a thread to
access the common resource (e.g. due to not executing a memory barrier) does not
seem to satisfy to the above definition.
Then of course another article (on memory barriers) written by other people does
not agree.. I do not see an issue with that. Probably they saw something called
"mutex" that required the mutex client code to additionally exercise memory
barrier.. in my and the Wikipedia first article's view it would not be a
complete mutex, anyway. I am fully content with being in this sort of
disagreement with one or more articles at Wikipedia.
/Leigh
-Pavel