From: "Johan Torp" <johan.torp@gmail.com> 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