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.