Re: [boost] Boost.Threads, N2178, N2184, et al

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-22 13:53:04

On Mar 22, 2007, at 1:14 PM, Yuval Ronen wrote:

>
>> The usual
>> idiom is to have the mutex at namespace scope, or as a class data
>> member, and have the lock referring to that mutex "on the stack".  So
>> for the usual idioms, non-copyable, non-movable mutexes do not seem
>> overly problematic.
>
> I'm not sure it's not problematic. If the mutex is class data member  
> (a
> very common scenario - perhaps the most common one), then it makes  
> that
> class non-movable. Non-copyable - I understand, but non-movable -  
> that's
> a major limitation, IMO.

I think we're ok here, both for copying and moving.  Here's a  
prototype class A which owns an int on the heap.  And because I think  
this is a cool use of the read/write locks from N2094 I'm going to use  
them to implement the copy assignment. :-)

I'm typing this code in untested, so please forgive me any careless  
mistakes.

class A
{
     int* the_data_;
     std::sharable_mutex mut_;

     typedef std::sharable_lock<std::sharable_mutex>  read_lock;
     typedef std::exclusive_lock<std::sharable_mutex> write_lock;
public:
     explicit A(int data) : the_data_(new int(data)) {}
     ~A() {delete the_data_;}

     // copy semantics
     A(const A& a) : the_data_(0)
     {
         read_lock lk(a.mut_);
         if (a.the_data_ != 0)
            the_data_ = new int(*a.the_data_);
     }
     A& operator=(const A& a)
     {
        if (this != &a)
        {
           read_lock lock_a(a.mut_, std::defer_lock);
           write_lock lock_this(mut_, std::defer_lock);
           std::lock(lock_this, lock_a);  // prevents deadlock
           int* new_data = a.the_data_ ? new int(*a.the_data_) :  
(int*)0;
           delete the_data_;
           the_data_ = new_data;
        }
        return *this;
     }

     // move semantics
     A(A&& a) : the_data_(a.the_data_)
     {
         a.the_data_ = 0;  // no locking required, a is an rvalue! :-)
     }
     A& operator=(A&& a)
     {
        write_lock lock_this(mut_);
        delete the_data_;
        the_data_ = a.the_data_;
        a.the_data_ = 0;
        return *this;
     }
};

I.e. you just move or copy the protected data and not the mutex.

The cool part here (imho) is the template <class Lock1, class Lock2>  
void std::lock(Lock1&,Lock2&) function.  You don't want to get into a  
situation like this without deadlock protection:

A a1, a2;

Thread 1       Thread 2
a1 = a2;        a2 = a1;

std::lock will do whatever it needs to do to lock both locks without  
deadlock (personally I'm a fan of the "try and back off" algorithm,  
but locking in a predefined order is also popular).  And std::lock can  
work with a heterogenous list of locks. :-)

-Howard