Re: question re. usage of "static" within static member functions of
a class
On Sep 10, 3:12 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Sep 9, 5:15 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:f0ed97f9-ea04-4952-88f2-a1982725a0b4@38g2000yqr.googlegroups.com...
You can get around static initialization and destruction
ordering issues by using a strongly thread-safe smart
pointer to manage the singleton. The pseudo-code would be
something like the following pseudo-code:
_____________________________________________________________________
template<typename T>
static local_ptr<T>
once()
{
static global_ptr<T> g_instance;
local_ptr<T> lptr(g_instance);
if (! lptr)
{
static pthread_mutex_t g_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&g_mutex);
lptr = g_instance;
if (! lptr)
{
try
{
lptr.reset(new T());
}
catch (...)
{
pthread_mutex_unlock(&g_mutex);
throw;
}
g_instance = lptr;
}
pthread_mutex_unlock(&g_mutex);
}
return lptr;
}
_____________________________________________________________________
This is strongly thread-safe and will always work no matter
how the static ctor/dtor ordering comes out. The caveat,
well, it's definitely not as efficient as using a raw
pointer and explicitly leaking the singleton.
There are so many things wrong with that code sample, I don't
even know where to start. (Exaggeration. I do know where to
start.)
Firstly and most importantly, you're using double checked
locking, which is broken in effectively all C++
implementations. Don't do that. Please read, continue to
re-read if you don't get it, this excellent
paper:http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
I doubt that Chris would have missed the issues addressed in
that paper. He doesn't tell us what local_ptr is, so it's hard
to say, but presumably, it takes steps to ensure the necessary
synchronization. (Double checked locking is possible, at least
on most platforms, provided you're not adverse to a little
assembler. It's not possible with just C++ and mutexes,
however, but I think it can be done under Posix using thread
local storage. Whether it's worth the bother is a different
question, given that much simpler solutions exist.)
Until we know what's behind local_ptr and global_ptr, however,
there's no way to be sure.
Next, you also have a race condition on the construction of
the mutex itself, in addition to the double checked locking of
the singleton instance construction. PTHREAD_MUTEX_INITIALIZER
is entirely equivalent to calling pthread_mutex_init, and thus
is not thread-safe.
No. PTHREAD_MUTEX_INITIALIZER is static initialization,
guaranteed to occur before any user written code is executed.
--
James Kanze