Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1850: request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-03-21 20:52:22
#1850: request for unlock_guard (and/or unique_unlock) to compliment
lock_guard/unique_lock
--------------------------------+-------------------------------------------
Reporter: bgreen0@⦠| Owner: viboes
Type: Feature Requests | Status: assigned
Milestone: Boost 1.36.0 | Component: thread
Version: Boost 1.35.0 | Severity: Not Applicable
Resolution: | Keywords: unlock_guard release_guard
--------------------------------+-------------------------------------------
Comment (by viboes):
I'm wondering if this features is not dangerous combined with other lock
guards. E.g. The user of lock_guard expects his lock to be locked during
his lifetime, so nesting a unlock_guard will break the user expectations.
I think that as far as we unlock we are transferring ownership, so the
safe way to nest the unlock guard is to use move semantics from a lock
owning the mutex. What do you think of a reverse_lock
{{{
template<typename Lock>
class reverse_lock
{
private:
Lock& m;
public:
reverse_lock(reverse_lock const&) = delete;
reverse_lock& operator=(reverse_lock const&) = delete;
typedef typename Lock::mutex_type mutex_type;
explicit reverse_lock(Lock& m_):
m(m_)
{
BOOST_ASSERT(m.owns_lock());
m.unlock();
}
reverse_lock(Lock& m_,adopt_unlock_t):
m(m_)
{
BOOST_ASSERT(!m.owns_lock());
}
~reverse_lock()
{
if(!m.owns_lock())
m.lock();
}
explicit operator bool() const BOOST_NOEXCEPT
{
return m.owns_lock(); // always false
}
bool owns_lock() const BOOST_NOEXCEPT
{
return m.owns_lock(); // always false
}
mutex_type* mutex() const BOOST_NOEXCEPT
{
return m.mutex();
}
mutex_type* release() BOOST_NOEXCEPT
{
return m.release();
}
};
}}}
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/1850#comment:4> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:09 UTC