Boost C++ Libraries: Ticket #1850: request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock

attachment set

bgreen0@… — Tue, 22 Apr 2008 23:20:03 GMT

attachment → lock.patch

patch adding unlock_guard to boost/thread/locks.hpp

viboes — Fri, 20 Nov 2009 12:39:37 GMT

The following prototype seems not clear to me

70	        unlock_guard(Mutex& m_,adopt_lock_t):
71	            m(m_)
72	        {}

For lock and unique lock adopt_lock_t parameter means adoption of the mutex was lock. For unlock_guard, adopt_lock_t will mean adoption of the mutex was unlock?

I would prefer a new structure

struct adopt_unlock_t {}
const adopt_unlock_t adopt_unlock={};
unlock_guard(Mutex& m_,adopt_unlock_t):
 	m(m_)
 	{}

Maybe is just an english language question I don't master.

type, severity changed

viboes — Sat, 27 Nov 2010 09:35:26 GMT

type Patches → Feature Requests
severity Problem → Not Applicable

As this patch doesn't provides test and documentation I think we can downgrade it to Feature Request. Please could you provide them?

owner, status changed

viboes — Thu, 05 Jan 2012 05:48:52 GMT

owner changed from Anthony Williams to viboes
status new → assigned

viboes — Wed, 21 Mar 2012 20:52:21 GMT

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();
        }
    };

attachment set

viboes — Sat, 31 Mar 2012 08:36:50 GMT

attachment → 1850.patch

viboes — Sat, 31 Mar 2012 08:38:42 GMT

Replying to viboes:

    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();
        }
    };

I have removed all the member operations as the goal is to ensure that the mutex is lock after destructor.

milestone changed

viboes — Sat, 31 Mar 2012 15:24:37 GMT

milestone Boost 1.36.0 → Boost 1.50.0

Committed in trunk revision 77662.

status changed; resolution set

viboes — Mon, 28 May 2012 15:07:58 GMT

status assigned → closed
resolution → fixed

Committed in release branch at [78543]