Re: [boost] [thread] is this reverse_lock class a source of errors?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-09 13:16:15

Hi Phil,

----- Original Message ----- 
From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 09, 2008 3:05 PM
Subject: Re: [boost] [thread] is this reverse_lock class a source of errors?

> vicente.botet wrote:
>>  {
>>      unique_lock<mutex> lock(smtx);
>>
>>      // ... some writing operations
>>
>>      { // non locked block
>>          reverse_lock< unique_lock<mutex> > rlock(lock);
>>          // ... some code not needing the mutex to be locked
>>      } // locked again
>>
>>      // ...
>> }
>
> I wrote something like this to use inside my condition variable
> implementation and called it "unlock".  I think I prefer the name
> "unlock" to "reverse_lock", personally.  In my case I have only a
> subset of the proposed C++0x mutex and lock functionality, making the
> implementation simpler and the potential for errors low.
>
> template <typename MUTEX_T>
> struct Unlock: boost::noncopyable {
>
>   typedef MUTEX_T mutex_t;
>
>   mutex_t& m;
>
>   explicit Unlock(mutex_t& m_): m(m_) {
>     m.unlock();
>   }
>
>   ~Unlock() {
>     m.lock();
>   }
>
>   mutex_t* mutex(void) {
>     return &m;
>   }
> };

Thanks for the explict contructor and the boost::noncopyable.

I have started implementing it like you, but the interaction with the 
nesting locks is not so clean (nesting_lock has ownership on mtx (1) which 
is not correct). Of course this class is clean if there is not a nesting 
lock and much more efficient.

{
      unique_lock<mutex> nesting_lock(mtx);

      // ... some writing operations

      { // non locked block
          reverse_lock< mutex > rlock(mtx); //   (1)
          // ... some code not needing the mutex to be locked
      } // locked again

      // ...
}

We can use the Operator Traits/Concept Traits library (Not yet submitet to 
Boost) and enable_if to create two partial specialization and have both 
classes with the same name.  I'm not sure that preserve the name is 
important, but I can, if nobody has already do it, define the BCCL Lockable 
Concepts and its concept traits counterparts.

Currently there are no concepts for the Boost.Thread locks, which seams 
quite natural because there is neither a class nor a function which takes a 
Lock as template parameter (except condition_variable_any::wait).  Has 
someone already defined the locks concepts?

> Once you have recursive mutexes, shared locks and the other features,
> the possible interactions start to get interesting.

The interaction with shared_lock seams to be OK. I don't see any problems 
with recursive_mutex. Could you show, if you have already identified, which 
interactions can be an issue?

> I have wondered
> whether a subset of the C++0x features, closer to the old Boost.Threads
> API, could be useful as a "threads-for-beginners" package.

Could you be more precise, to which subset are you referring?

Best

Vicente