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

It appears to me that the mutex would *always* be destroyed before the guard. Objects are always destroyed in the reverse of their construction order, and (if I'm not mistaken) the construction order of static data members is the order in which they are declared. Given this, the declaration order should be changed to: static Singleton *instance; static boost::mutex mutex; static Guard guard; Mike "Stefan Seefeld" <seefeld@sympatico.ca> wrote in message news:68f54c8a71bfd0761dd5bbe469329e29406c69fb@Orthosoft.ca... 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 application lock-up when the Singleton::Destroy() (called from the guard destructor) attempts to aquire the lock. Is there a way around this dilemma ? During debugging I set the 'm_mutex' member of the mutex class (which is a CRITICAL_SECTION) to zero right after deletion, which worked, i.e. there was no lock-up. I'm not sure though that this is the correct thing to do.

Any suggestions ?

Thanks, Stefan

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost