Boost logo

Boost :

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

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