RE: [boost] problem with global mutex object on windows

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Friday, 2 April 2004 4:59 AM To: boost@lists.boost.org Subject: [boost] problem with global mutex object on windows
hi there,
we'v run into a problem with the boost_thread mutex class, when used as a global object.
Imagine a singleton class as
class Singleton { public: static Singleton *GetInstance(); static void Destroy(); private:
struct Guard { ~Guard() { Singleton::Destroy();} }; static Singleton *instance; static Guard guard; static boost::mutex mutex; };
where the internal access to 'instance' is serialized by means of the mutex (inside methods GetInstance() and Destroy()).
It is the Singleton::Guard destructor that is responsible to free the instance (if it isn't destructed already). It, too, uses the mutex to protect access.
In a specific context on windows xp it happened that the mutex variable was destructed before the guard, leading to a global
3.6.2 Objects with static storage duration .. shall be initialized in the order in which their definition appears in the translation unit. 3.6.3 ... These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization. So as long as the Singleton::Guard definition is before the definition of the mutex it should work. I assume that despite having the definitions in that order it doesn't work? Does that make it a compiler bug or am I missing something? In any case, I'm not convinced that this is sufficient to make your singleton useful. Do you know that GetInstance isn't called by the constructor of a static object? Do you know that no other threads (which might call GetInstance) are started prior to the mutex being constructed? I haven't tried to get a truly thread-safe singleton working - I remember several discussions about it here - but I'm not sure that any of them resulted in an efficient working solution? Sorry - perhaps not an altogether helpful response. Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Friday, 2 April 2004 4:59 AM To: boost@lists.boost.org Subject: [boost] problem with global mutex object on windows
hi there,
we'v run into a problem with the boost_thread mutex class, when used as a global object.
Imagine a singleton class as
class Singleton { public: static Singleton *GetInstance(); static void Destroy(); private:
struct Guard { ~Guard() { Singleton::Destroy();} }; static Singleton *instance; static Guard guard; static boost::mutex mutex; };
where the internal access to 'instance' is serialized by means of
"Darryl Green" <Darryl.Green@unitab.com.au> wrote in message news:4FCBBCDBF9232241B8D2031F2DD74DCBC01D96@BRISBANEMAIL1.brisbane.tabq.com... the
mutex (inside methods GetInstance() and Destroy()).
It is the Singleton::Guard destructor that is responsible to free the instance (if it isn't destructed already). It, too, uses the mutex to protect access.
In a specific context on windows xp it happened that the mutex variable was destructed before the guard, leading to a global
3.6.2 Objects with static storage duration .. shall be initialized in the order in which their definition appears in the translation unit.
Yes.
3.6.3 ... These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization.
Yes.
So as long as the Singleton::Guard definition is before the definition of the mutex it should work. I assume that despite having the definitions in that order it doesn't work? Does that make it a compiler bug or am I missing something?
So unless I'm being dense, wouldn't you want to have the definition of the Guard *after* that of the mutex? That way the mutex would be created before the Guard and destroyed after the guard. Since the guard uses the mutex (via the call to Destroy), this seems like a good idea.
In any case, I'm not convinced that this is sufficient to make your singleton useful. Do you know that GetInstance isn't called by the constructor of a static object? Do you know that no other threads (which might call GetInstance) are started prior to the mutex being constructed?
I haven't tried to get a truly thread-safe singleton working - I remember several discussions about it here - but I'm not sure that any of them resulted in an efficient working solution?
Sorry - perhaps not an altogether helpful response.
Darryl.
participants (2)
-
Darryl Green
-
Michael Glassford