Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-25 14:52:01

Peter Dimov wrote:
> Yuval Ronen:
> 
>> Peter Dimov wrote:
> 
>>> I meant "helps people avoid accidental mistakes at the time they're 
>>> writing
>>> the code". The function encourages correct use by asking for a lock,
>>> implying that the mutex needs to be locked first.
>> Hinting the user to lock a mutex by accepting a lock is getting too
>> psychological for my taste. If it was enforced by the compiler, then
>> maybe, but since the compiler can't...
> 
> The hint isn't particularly subtle. You have to pass a lock, and this _is_ 
> enforced by the compiler. The rest of the enforcement (that the lock 'owns' 
> the correct mutex) is necessarily postponed to run time; we simply can't do 
> better than that.
> 
> I'm really not sure how you propose to achieve the same level of encouraging 
> and enforcing correct use with a wait function that doesn't take a lock 
> argument,

I'm saying that there's no need to achieve the same level of enforcing. 
Checking in runtime is enough, IMO. Just as we don't enforce locking 
before accessing a shared resource (because we can't), there's no need 
to go over hoops (see my next paragraph) to enforce more than at runtime.

> and I'm also unsure what specific problems with requiring a lock 
> argument are you trying to solve. 

I find the lock argument cumbersome. In a way it's redundant to passing 
the mutex, and for no good reason - just for hinting, subtle or no 
subtle. Where else in C++ a user is hinted in such a way? It's without 
precedent, and plain weird in my eyes. And if we add to this the fact 
that it's only a partial compile-time check, then it makes things even 
weirder. The user, for example, can confuse and think that he is fully 
covered by the compile-time check, and continue with his guards down, 
passing it a non-owning unique_lock. If we can't do a complete job, it's 
better to not do it at all, at least this way our users are forced to be 
aware of what's happening.