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:
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk