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

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-09-08 10:36:06

> From: William Kempf [mailto:sirwillard_at_[hidden]]

> --- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:

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

I saw that.  I should have been more clear.  If some high-level function
gets a lock (for some reason not directly related to the cv) it may be
"surprised" that lower level code released the lock and allowed other
threads to grab the mutex and mess with "locked" resources.

It is not uncommon to lock two resources with one mutex (given recursive
mutexians it eliminates one opportunity for deadlock).  It isn't enough for
wait() to "properly" handle the recursive mutex, the high level code must be
willing to allow for the case that low-level code might pick the lock,
without even having access to the hi-level lock object (the low level code
probably has access to just the mutex object and its own low-level lock
object).