Re: Singleton_pattern and Thread Safety

From:

"Chris M. Thomasson" <cristom@charter.net>

Newsgroups:

comp.lang.c++

Date:

Sat, 11 Dec 2010 18:01:52 -0800

Message-ID:

<j2WMo.492$My1.146@newsfe16.iad>

"Chris M. Thomasson" <cristom@charter.net> wrote in message
news:bHPMo.464$My1.55@newsfe16.iad...

"Leigh Johnston" <leigh@i42.co.uk> wrote in message

template<typename T>
T& meyers_singleton()
{
       static T* g_global = NULL;
       T* local = ATOMIC_LOAD_DEPENDS(&g_global);

       if (! local)
       {
           static pthread_mutex_t g_mutex = PTHREAD_MUTEX_INITIALIZER;
           thread* const self_thread = pthread_get_specific(...);

           pthread_mutex_lock(&g_mutex);
00: static T g_instance;

           // simulated memory release barrier
01: pthread_mutex_lock(&self_thread->m_acquire);
02: pthread_mutex_unlock(&self_thread->m_release);
03: pthread_mutex_lock(&self_thread->m_release);
04: pthread_mutex_unlock(&self_thread->m_acquire);

here is a simplification:

           // simulated memory release barrier
           pthread_mutex_unlock(&self_thread->m_release);
           pthread_mutex_lock(&self_thread->m_release);

No code below the lock can rise above it, and no code above the unlock can
sink below it.

This will produce proper release barrier on many existing POSIX
implementations for a plurality of architectures. I cannot think of a
PThread mutex implementation that gets around all explicit membars in the
internal `pthread_mutex_lock/unlock' code.

I do know of some Java proposals...

           // atomically produce the object
05: ATOMIC_STORE_NAKED(&g_global, &g_instance);
06: local = &g_instance;

           pthread_mutex_unlock(&g_mutex);
       }

   return local;
}
___________________________________________________________