Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk