From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-08 10:09:54
--- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:
> > From: William Kempf [mailto:sirwillard_at_m...]
> > --- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> > > [ Allow a MutexLock::lock class to have lock() and unlock()
> 1) LF's intention may have been "require" rather than "allow".
> his intention was "allow".
> 2) Based on the current write-up it is allowed, just as it might
> FlapWings() member. However WK is arguing that it should not be
> He wants to know that living lock objects are locked. In
> > Fail to lock a mutex and call
> > condition::wait() and you've got undefined behavior.
> The mutex object used for locking a cv should be locked exactly
> have the cv's associated mutex::lock class support unlock(). Don't
> cv's associated mutex be a RecursiveMutex either. I don't believe
that is a
> reason to outlaw RecursiveMutex, or to say it does not meet the
Almost. Recursive mutexes are fine, so long as the condition class
can handle this. The Win32 implementation I have posted allows the
recursive_mutex to work with condition with out problems. Check out
> > (with a more
> > complex requirement on this we could have this result in a runtime
> > error,
> as could nested locks
> > but this is dangerous because of my next point). Fail to
> > unlock the mutex and you get a runtime error... a deadlock!
> Lock objects that currently hold a lock should always release the
> many levels as it holds) on destruction. That doesn't particularly
> be a reason to require lock objects to always hold a lock.
The reason they should always hold a lock is to allow for compile
time assertions on this fact. For instance, condition::wait() takes
a lock instead of a mutex because this allows us to prevent wait()
from being called at compile time if the mutex isn't locked. This is
a huge safety benefit, and it doesn't cost us anything, despite the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk