Re: [boost] Boost.Threads Locking Delima

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-17 11:42:18

From: "William E. Kempf" <williamkempf_at_[hidden]>
>
> This doesn't cause you to not know the exact lifetime of the lock... it
just
> means the programmer had better understand the rules of move semantics.
In
> other words, as long as you pay attention to how move semantics work this
is
> a very deterministic mechanism for lock management, as opposed to say how
> shared_ptr works.

shared_ptr is completely deterministic, too. If you pay attention, you'll
never go wrong. The problem is that it's more flexible, and a shared lock
would probably be easier to misuse if you don't pay attention.

> If you know the rules of move semantics this isn't a case where you'd lose
> the lock but didn't expect to.  The problem is, as with auto_ptr, newbies
> don't understand the rules of move semantics so *they* are surprised.

The problem is that, at present, we don't have a language construct with
which to express move semantics. std::auto_ptr uses pass by value, and this
is what confuses newbies and veterans alike. Pass by value is not supposed
to alter the original.

Do we need to transfer locks into functions? Perhaps locks need an even more
restricted version of 'move semantics', that supports return by value only.