|
Boost : |
From: alnsn_at_[hidden]
Date: 2004-07-09 11:44:44
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk