Re: [Boost-bugs] [Boost C++ Libraries] #1850: request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock

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-31 08:38:42

#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):

 Replying to [comment:4 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/1850#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.