Boost logo

Boost :

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-09-08 09:25:56

> From: William Kempf [mailto:sirwillard_at_[hidden]]
> --- 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

> 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

> (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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at