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
> > 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
> > 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
> 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.
> > > 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()
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk