Will boost::recursive_mutex::scoped_locks destructor reference an unlocked mutex?
After calling unlock()
on a boost::recursive_mutex::scoped_lock
, will the lock object reference the mutex somehow in 开发者_StackOverflowits destructor?
The lock still retains a reference to the mutex after the call to unlock (ie. mutex()
returns the same pointer). Must release()
also be called on the lock in the case where the mutex is destroyed before the lock goes out of scope?
Looking at the code for the unique_lock destructor from Boost 1.42:
~unique_lock()
{
if(owns_lock())
{
m->unlock();
}
}
It will only try to dereference its pointer to your (now invalid) mutex if it owns the lock. If you've already called unlock on this scoped_lock then it shouldn't cause you problems in this implementation (which, although unlikely, could change in future versions of the library).
However, it's best practise to ensure your objects are destroyed in an order such that dependent objects are destroyed before their dependencies. If you cannot guarantee this then, as you rightly say, you should call release() on the lock before destroying the mutex.
精彩评论