[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Eric Niebler (eric_at_[hidden])
Date: 2004-07-09 12:59:51

alnsn_at_[hidden] wrote:
> 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));
> 

Oh yeah, I heard a talk by Andrei Alexandrescu in which he endorsed that 
idiom. (Google for "Honey I shrunk the threads".) I like it, but I've 
never used it. :-P

Actually, in the design I was suggesting, there is only one lock type, 
so you don't have to mess with multiple types, temporaries bound to 
const references, or a common base class. This idiom becomes easier to 
use, IMO, with only one lock type.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com