RE: [boost] Re: Threads: New Win32 Implementation

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

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