RE: [boost] Boost.Threads Locking Delima

From: Darryl Green (green_at_[hidden])
Date: 2002-05-19 19:56:25

> -----Original Message-----
> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> 
> Then how about a variation on the auto_ptr interface.  
> Instead of using the
> same syntax for "move semantics" as you would for "copy semantics" the
> ScopedLock can provide a "move" operation that returns a 
> proxy for which
> another ScopedLock may be constructed from.  So this:
> 
> ScopedLock lock1(mutex);
> ScopedLock lock2(lock1);
> 
> would be illegal while this:
> 
> ScopedLock lock1(mutex);
> ScopedLock lock2(lock1.move());
> 
> would provide auto_ptr like move semantics.  If we choose the 
> right name for
> "move" this could discourage users from "passing locks" 
> unless it's needed
> and the code is self documenting exactly what's occuring, 
> unlike the syntax
> for auto_ptr move semantics.  Would this be more pallatable?

The move proxy is a great solution. It preserves all the good features of
the existing ScopedPointer while allowing move in a way that I don't find
any uglier than the alternatives (ok, it is uglier than the auto_ptr option,
but the auto_ptr's beauty seems to be a bit treacherous).
  
> (If so, I
> still question whether or not this totally resolves issues 
> with needing
> lock/unlock in different "scopes").

I assume the question applies equally to the auto_ptr model? Or am I missing
something? I did think about this when looking at your original RFC, but I
couldn't think of a case it didn't deal with - not that that proves much.

> 
> 
> Does the above syntax work for you in this regard?  If not, 
> do you have any
> thoughts on how else to expose this?

It certainly does.

Darryl Green.