request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock

[bgreen0@…]

I'd like to request an unlock_guard class template to complement lock_guard. I wonder if it is any more involved than the attached patch. A unique_unlock class template may be nice as well, but an unlock_guard seems sufficient.

Is there a known reason it was left out of the proposal for the C++0x thread library, or is it a simple oversight? I don't see any reference to it in the documents.

[bgreen0@…]

patch adding unlock_guard to boost/thread/locks.hpp

[viboes]

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.

[viboes]

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

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

[viboes]

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

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

[viboes]

Committed in trunk revision 77662.

[viboes]

Committed in release branch at [78543]