Re: Singleton_pattern and Thread Safety
On Dec 11, 3:05 am, Leigh Johnston <le...@i42.co.uk> wrote:
On 11/12/2010 02:38, Leigh Johnston 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:
[...]
Normally I instantiate all my singletons up front (before
threading)
That's really the only acceptable solution. (And to answer
Leigh's other point: you don't use singletons in plugins.)
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.
Sorry I was worrying over nothing; of course the C++ compiler
will not reorder a pointer assignment to before the creation
of the object it points to ..
Really? What makes you think that? (And of course, even if the
compiler doesn't reorder, the hardware might.)
The code posted above is broken on so many counts, it's hard to
know where to start. It is basically just the double checked
locking anti-pattern, known to not work. (See, for example,
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf.)
With, in addition, the fact that there doesn't seem to be
anything which guarantees that sLock is constructed before it is
used.
no volatile needed! :)
In C++, the volatile wouldn't buy you anything; some versions of
Visual Studios do extend the meaning so that it could be used,
but this was (I believe) a temporary solution; presumably,
future versions will adopt the definition of volatile adopted in
C++0x.
--
James Kanze