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()
members ]
>
> 1) LF's intention may have been "require" rather than "allow".
I'll assume
> his intention was "allow".
>
> 2) Based on the current write-up it is allowed, just as it might
have a
> FlapWings() member. However WK is arguing that it should not be
allowed.
> He wants to know that living lock objects are locked. In
particular WK
> writes:
>
> > 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
once. Don't
> have the cv's associated mutex::lock class support unlock(). Don't
let the
> 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
LockMutex
> requirements.
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
the implementation.
> > (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
lock (as
> many levels as it holds) on destruction. That doesn't particularly
seem to
> 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
concern raised.
Bill Kempf