Re: Threads: New Win32 Implementation

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