Re: Singleton_pattern and Thread Safety

From:

Leigh Johnston <leigh@i42.co.uk>

Newsgroups:

comp.lang.c++

Date:

Wed, 15 Dec 2010 15:13:18 +0000

Message-ID:

<OdudnW1JtPmYRpXQnZ2dnUVZ8tudnZ2d@giganews.com>

On 15/12/2010 15:05, Yannick Tremblay wrote:

In article<iaKdnSCbDLNQHZrQnZ2dnUVZ7vCdnZ2d@giganews.com>,
Leigh Johnston<leigh@i42.co.uk> wrote:

On 14/12/2010 11:57, Yannick Tremblay wrote:

In article<Wq-dnZ_zTIKEj5vQnZ2dnUVZ8mCdnZ2d@giganews.com>,

In order to save yourself from some "not explicitely dellocated"
object that would only cause a problem in some very special cases, you
initially implemented a singleton class that appeared to be thread
safe but was not. Now had you not been a poster here, you may have
put this class in an application and you or another programmer may
well have used this singleton blindly in the middle of multi-threaded
code where it could have cause a real serious and very hard to track
problem.

Your fixed singleton class is now better but the fact that you needed
to fix it after having so happily posted the first version here just
highlights the problems it could have caused.

The initial version I posted would have worked fine on the
implementation I am using; I never claimed it was portable.

It still is a potential bug. Could well have caused real problem down
the line.

A far as effect on the system, for almost all purposes there is no
difference between what you call a leaky singleton and a global
variable. Both get instantiated before entering main and both get
cleaned up by the OS, both are thread safe, neither will cause a bug.

As far as effect on the system, there's a fundamental difference
between your initial proposal, James' proposal and a global variable:
yours was a bug waiting to be triggered.

The real world equivalent is that you would have checked it in the
code base, it may well have passed a basic code review and would
alomost certainly have passed application level testing and been
released to customers. Then once in a while, a customer would phone
in with a strange report of data corruption.

Not on the implementation I wrote it for.

This is a valid point. But if it applies to you, it must apply to
James too. What you call a "leaky" singleton is perfectly fine for
the application it was written for. A place it would not fine is with
your suggested dll plugins load/unload example.

Try and get into the habit of replying to terminal nodes in a usenet
thread as the discussion has moved on. My singleton template currently
looks like this:

namespace lib
{
    template <typename T>
    class singleton
    {
    public:
        static T& instance()
        {
            T* ret = sInstancePtr;
            memory_barrier_acquire_dependant();
            if (ret == 0)
            {
                lock theLock(sLock);
                static T sInstance;
                memory_barrier_release();
                sInstancePtr = &sInstance;
                ret = sInstancePtr;
            }
            return *ret;
        }
    private:
        static lockable sLock;
        static T* sInstancePtr;
    };

    template <typename T>
    lockable singleton<T>::sLock;
    template <typename T>
    T* singleton<T>::sInstancePtr;
}

/Leigh