From: Csaba Szepesvari (szepes_at_[hidden])
Date: 2000-09-14 10:59:13
> 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
> > 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.
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). That was
the point here (`resource acquisition as initialization').
Another trait is whether the lock allows multiple calls to lock() that is
really a separate issue (both can be made exception safe).
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk