Peter Dimov wrote:
- you can return a lock from a function: we can make the locks movable regardless of the interface, so it seems possible to ignore this bullet;
- if( lock l = try_lock( m ) ) { }
This is the main difference.
Declarations in conditions are a nice idiom. The typical use is
if( X x = f() ) { // do something with x }
Our example doesn't fit the pattern, however, as the "// do something" part typically does not reference the lock itself.
This is a degenerate case of more general idea of passing lock reference to functions inside condition: if(lock_ref l = scoped_lock(m)) { // do something with l: action1(l); action2(l); } Apparently, action1 and action2 can't be called without prior obtaining of a lock. Plus, you get some sort of polymorphism because the functions can accept other locks as well: action1(scoped_try_lock(m1)); // lock_ref is const reference action2(scoped_timed_lock(m2)); The only big problem I know of so far is unspecified order of calls in the case of getting multiple locks (incorrect order leads to deadlock): action3(scoped_lock(m1), scoped_lock(m2)); -- Alexander Nasonov