Re: thread lock/unlock example

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 11:14:36

--- In boost_at_[hidden], Csaba Szepesvari <szepes_at_m...> wrote:
> > You do not want the lock to do recursive locking.  This is a 
trait of
> > the mutex, not the lock.  This interface is also less safe, since 
it
> > removes any hope for compile time checking of the lock status in
> > calls such as condition::wait().  I did, however, provide just 
such a
> > lock called unsafe_lock<> that used the currently available 
interface
> > to achieve this!  So you really are unlikely to convince me here.
> >
> 
> You might have missed the point that I also used another type 
`alock' to
> avoid this.

No, I didn't.  I explained it better in an early post.  The lock 
class (alock or what ever name you choose to use) should not add 
recursive locking to a non-recursive mutex, and a recursive lock is 
pointless when you have a recursive mutex.

> Also:
> 
> > > Having the two types of locks differing only in a template
> > parameter and letting the
> > > default be the one that disables the lock() method would also 
mean
> > that people would
> > > use the one exposing lock() only when they really need that one.
> >
> > That's what I said when I posted the unsafe_lock<> ;).
> >
> 
> I know, just forgot to refer that. Sorry.
> 
> Recursive locks: With conditions, of course, you do not want 
recursive
> locks. That's solved by having two types.

You need only one type.  Recursive locking is only useful for 
recursive function calls, in which case you'll be creating new locks 
on a recursive mutex.  A recursive lock is redundant and violates the 
concept of a non-recursive mutex.
 
> Having the lock() exposed on the interface of a lock type yields
> exception safety provided that the lock knows how many times to 
unlock
> (could be zero or one, better a bool, for a non-recursive lock).

It should be a non-recursive lock, which is precisely how 
unsafe_lock<> was implemented.

> Another trait is whether the lock allows multiple calls to lock() 
that is
> really a separate issue (both can be made exception safe).

Multiple calls means recursive calls which, again, is a trait of the 
mutex not of the lock.  They should not be allowed in unsafe_lock<>, 
resulting in an exception or some other error state.
 
> what about lock<auto> and lock<manual> and auto would be the 
default so
> lock<> would just work nicely.
> Also, you could have lock_impl<xx> and typedef lock<auto> to lock.

How is the implementation currently in the Win32 code failing you 
here?  Why do you want to complicate things with a lock_impl<>?

Seriously, I can't comprehend why we still have an issue here.

Bill Kempf