boost::recursive_mutex::scoped_locks 析构函数会引用未锁定的互斥体吗？
在 boost::recursive_mutex::scoped_lock 上调用 unlock() 后，锁定对象是否会在其析构函数中以某种方式引用互斥体？
在调用解锁之后，锁仍然保留对互斥锁的引用（即 mutex() 返回相同的指针）。如果互斥锁在锁超出范围之前被销毁，是否还必须在锁上调用release()？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
查看 Boost 1.42 中 unique_lock 析构函数的代码：
如果它拥有锁，它只会尝试取消引用指向您的（现在无效）互斥体的指针。如果您已经对此scoped_lock调用了unlock，那么它不会导致您在此实现中出现问题（虽然不太可能，但可能会在库的未来版本中发生变化）。
但是，最佳实践是确保按顺序销毁对象，以便依赖对象在其依赖项之前被销毁。如果你不能保证这一点，那么，正如你所说，你应该在销毁互斥体之前对锁调用release()。
Looking at the code for the unique_lock destructor from Boost 1.42:
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.