Re: [boost] Re: Lock unification [move]

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-19 07:47:18

Howard Hinnant wrote:
> I have attempted a specification of moving
> scoped_lock/read_lock/upgradable_read_lock/write_lock at:
>
> http://home.twcny.rr.com/hinnant/cpp_extensions/threads.html
>
> This is an attempt to look forward to locks+move semantics, taking
> into account the recent discussions.  Because of the length of the
> specification I put it in an html on my personal website instead of
> stuffing it into an email.  Comments welcome.  Any response from me is
> likely to be delayed by several days due to travel.

I mostly agree with Bronek Kozicki. Given a movable lock, Eric Niebler's
proposal:

    scoped_lock try_lock( Mutex & m );
    scoped_lock timed_lock( Mutex & m );

is a better try/timed interface. Heisenberg constructors must die.

Also, I still think that the bool parameter is better than a "locking" enum,
as evidenced by the use case shown in the specification:

    scoped_lock lock( m, want_to_lock? locking: non_locking );

I find this an unnecessarily verbose and contrived way to express

    scoped_lock lock( m, want_to_lock );

which is the original intent.

I disagree that

    void * mutex() const;

is a better mutex() accessor. On the contrary, I'd argue that mutex() should
return a non-const mutex_type. A const return doesn't make a lot of sense
given that our mutexes have no const member functions; the private interface
is a better protection than the const. On the other hand, a non-const return
allows the client to use scoped_lock<> on user-defined mutex types (in
implementing the user-defined condition::wait, for example).

I also like the proposed scoped_lock == write_lock unification.