Re: [boost] [thread] Expected behaviour of condition variable wait when the mutex is not locked

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-07 10:37:52

From: "Johan Torp" <johan.torp_at_[hidden]>
Sent: Tuesday, May 06, 2008 3:07 PM
Subject: Re: [boost] [thread] Expected behaviour of condition variable wait 
when the mutex is not locked

>
> I'm not sure what's best in this case. I find that there is often a 
> certain
> trade-off between ease of use and runtime insecurities.

Yes you are right, we need to maintain a ease of use. Could you show me why 
my proposal using a strict_lock is  not easy to use?

Anyway I prefer (as most of you) to spend time solving compile time problems 
before my application is delivered than debuging on the field runtime code 
and look that the problem could be solved by the compiler.
If a condition_variable must have its mutex locked, why not provide an 
interface that can 'ensure' that at compile time, if we can do it?
If different mutexes are supplied for concurrent wait() operations on the 
same condition variable means undefined behaviour, why not check it.

I don't understand why we can not wait on a condition_variable once we have 
a lock_guard (which is more strict than the unique_lock). But I'm surely 
missing something. And why not to add another wait operation which is safe, 
or in the worst case more safe than the current ones? Maybe some of the C++ 
experts can clarify all these questions.

In any case, we can always define a strict_condition class based on the 
boost::condition_variable class having a strict lock as parameter of the 
wait operation.

void strict_condition::wait(strict_lock<mutex>& lock) {
    // add here all the needed/wanted runtime checks
    unique_lock<mutex> ulock(lock); // strict_lock must define a conversion 
operator without locking
    cnd_.wait(ulock); //cnd_ is a boos::condition_variable
    ulock.release(); // the mutex should not be unlocked
}

Even if we can do this wrapping I don't understand why we need to waste in 
CPU cycles when we can do without.

BTW, I think that you should preserv the context on your next posts, it 
would be easier for the others to follow.

Best regrads
_____________________
Vicente Juan Botet Escriba