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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-08 11:57:04

Howard Hinnant wrote:
> 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.

[reordered]

> 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.

This is a concern. However, I'm not sure that the noncopyable lock interface
is necessarily inferior and cannot be made forward compatible.

> 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.

I see no harm in allowing the "legacy" interface to function unmodified
after the transition to moveable locks. (Or is it movable locks? You should
really decide on that -eable vs -able thing, non-native speakers are getting
confused. Think of the children.)

I know that

    Classes should never move with copy syntax [Hinnant]

but in this case the constructor that "moves" an upgradable_read_lock
(upgradeable_read_lock?) to a write_lock is explicit, and it isn't a copy
constructor. Likewise, I see no harm in retaining x.transfer_to( y ); as an
alias to y = move(x).