Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-01 14:55:38


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_at_[hidden]> wrote in message
news:68f54c8a71bfd0761dd5bbe469329e29406c69fb_at_Orthosoft.ca...
> 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
> 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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk