
FYI Matthew Wilson gave a technique (in "Imperfect C++") for handling this, by turning the mutex initialization into an integer initialization (that doesn't have a problem with [multiple] simultaneous threads entering the function) It uses STLSoft's spin_mutex, and looks pretty much like what you have already: <code> #include <platformstl/spin_mutex.hpp> #include <stlsoft/lock_scope.hpp> using platformstl::spin_mutex; using stlsoft::lock_scope; template<typename T> boost::shared_ptr<T> my_func() { // static boost::mutex m; // boost::mutex::scoped_lock l(m); static int spin_count = 0; // No race condition initializing an int spin_mutex mutex(&spin_count); // Build the mutex on top of the static int lock_scope lock(mutex); static boost::shared_ptr<T> p(new T); return p; } </code> This assumes, of course, you can (and are willing to) use STLSoft... HTH, Pablo "James E Taylor" <james@onalog.net> wrote in message news:200508171519.j7HFJ1D0027677@marge.onalog.net...
I hope this isn't a stupid question, but....
Is the boost mutex constructor thread-safe?
I am writing a singleton template and trying to avoid the static initialisation/destruction order fiasco.
I envisage two threads accessing a function like this concurrently:
template<typename T> boost::shared_ptr<T> my_func() { static boost::mutex m; boost::mutex::scoped_lock l(m);
static boost::shared_ptr<T> p(new T); return p; }
and my worry is that both threads could attempt to do the static initialisation of m concurrently. Is there protection against this? Is it even possible to protect against this?
I've tried to use boost::call_once, which would give sufficient guarantees but it's quite inflexible as nothing can be passed to or from the function being called.
I know that integral types (like a pthread_t) of static storage are initialised before main() and before constructors of statically allocated objects are called, which means there would be no problem using a pthread_t above. However, constructors of objects of static storage are called at a time when there could be multiple threads running.
Am I worrying about nothing? Or is there a problem here?
Thanks, James
-- James E Taylor