[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-08 11:26:44

On Jul 8, 2004, at 11:10 AM, David Abrahams wrote:

> Are there really any repercussions from making a noncopyable type into
> a moveable type, other than that you might want to find ways to take
> advantage of the new moveability?

If I had an rvalue reference available today, I would design the 
interface of the read and write locks differently.  For example, 
instead of:

     void f(rw_mutex& m)
     {
         rw_mutex::upgradable_read_lock r(m);
         if (...)
         {
             rw_mutex::write_lock w(r);
             //...
             w.transfer_to(r);
         }
         //Point A
     }

I would propose:

     void f(rw_mutex& m)
     {
         rw_mutex::upgradable_read_lock r(m);
         if (...)
         {
             rw_mutex::write_lock w(move(r));
             //...
             r = move(w);
         }
         //Point A
     }

The original code would not compile:  write_lock would not accept an 
lvalue upgradable_read_lock and transfer_to would not exist.

This would allow, among other things, locks to be returned from 
functions (as long as they were auto-local within the function).  It 
would also allow for containers of locks.

So the major repercussion that I see is that we're designing an 
inferior interface today that is not forward compatible with what I 
would propose if move semantics were available.

We could possibly fake the desired move syntax today, but the thought 
makes me tired. :-(  Especially in the light that the proposed move 
syntax is by no means a sure deal.

-Howard