Re: Singleton_pattern and Thread Safety
On 11/12/2010 03:40, Joshua Maurice wrote:
On Dec 10, 7:17 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 11/12/2010 03:12, Joshua Maurice wrote:
On Dec 10, 6:38 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 11/12/2010 02:23, Leigh Johnston wrote:
On 10/12/2010 23:31, Ian Collins wrote:
On 12/11/10 10:08 AM, Leigh Johnston wrote:
On 10/12/2010 20:39, Ian Collins wrote:
On 12/11/10 09:21 AM, Leigh Johnston wrote:
Not considering object destruction when designing *new* classes is bad
practice IMO. Obviously there may be problems when working with
pre-existing designs which were created with a lack of such
consideration.
A programmer seldom has the benefit of a green field design. Even when
he or she does, there are still the dark and scary corners of the
language where undefined behaviour lurks. Order of destruction
issues is
one such corner, especially when static objects exist in multiple
compilation units.
I am well aware of the unspecified construction/destruction order
associated with globals in multiple TUs and that is primary reason why
this method of James's should be avoided. The order of destruction of
"Meyers Singleton" objects *is* well defined for example although making
the "Meyers Singleton" method thread safe is not completely trivial.
That is another pattern I use, but as you say, it has issues of its own.
Normally I instantiate all my singletons up front (before threading) but
I decided to quickly roll a new singleton template class just for the
fun of it (thread-safe Meyers Singleton):
namespace lib
{
template<typename T>
class singleton
{
public:
static T& instance()
{
if (sInstancePtr != 0)
return static_cast<T&>(*sInstancePtr);
{ // locked scope
lib::lock lock1(sLock);
static T sInstance;
{ // locked scope
lib::lock lock2(sLock); // second lock should emit memory barrier here
sInstancePtr =&sInstance;
}
}
return static_cast<T&>(*sInstancePtr);
}
private:
static lib::lockable sLock;
static singleton* sInstancePtr;
};
template<typename T>
lib::lockable singleton<T>::sLock;
template<typename T>
singleton<T>* singleton<T>::sInstancePtr;
}
Even though a memory barrier is emitted for a specific implementation of
my lockable class it obviously still relies on the C++ compiler not
re-ordering stores across a library I/O call (acquiring the lock) but it
works fine for me at least (VC++). I could mention volatile but I
better not as that would start a long argument. Roll on C++0x.
If I'm reading your code right, on the fast path, you don't have a
barrier, a lock, or any other kind of synchronization, right? If yes,
you realize you've coded the naive implementation of double checked?
You realize that it's broken, right? Have you even read
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
?
To be clear, this has undefined behavior according to the C++0x
standard as well.
I am aware of double checked locking pattern yes and this is not the
double checked locking pattern (there is only one check of the pointer
if you look). If a pointer read/write is atomic is should be fine (on
the implementation I use it is at least).
You've hidden the second check with the static keyword.
Example: Consider:
SomeType& foo()
{
static SomeType foo;
return foo;
}
For a C++03 implementation, it's likely implemented with something
like:
SomeType& foo()
{
static bool b = false; /*done before any runtime execution, stored
in the executable image */
static char alignedStorage[sizeof(SomeType)]; /*with some magic
for alignment */
if ( ! b)
new (alignedStorage) SomeType();
return * reinterpret_cast<SomeType*>(alignedStorage);
}
That's your double check.
For C++0x, it will not be implemented like that. Instead, it will be
implemented in a thread-safe way that makes your example entirely
redundant.
The problem with the traditional double checked locking pattern is twofold:
1) The "checks" are straight pointer comparisons and for the second
check the pointer may not be re-read after the first check due to
compiler optimization.
2) The initialization of the pointer may be re-ordered by the CPU to
happen before the initialization of the singleton object is complete.
I think you are confusing the checking issue. I am acquiring a lock
before this hidden check of which you speak is made and this check is
not the same as the initial fast pointer check so issue 1 is not a problem.
As far as issue 2 is concerned my version (on VC++ at least) is solved
via my lock primitive which should emit a barrier on RAII construction
and destruction and cause VC++ *compiler* to not re-order stores across
a library I/O call (if I am wrong about this a liberal sprinkling of
volatile would solve it).
I should have stated in the original post that my solution is not
portable as-is but it is a solution for a particular implementation
(which doesn't preclude porting to other implementations). :)
/Leigh