1

After calling unlock() on a boost::recursive_mutex::scoped_lock, will the lock object reference the mutex somehow in its 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?

jotik
  • 17,044
  • 13
  • 58
  • 123
Viktor
  • 3,295
  • 2
  • 25
  • 26

1 Answers1

1

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.

NNN
  • 386
  • 1
  • 9