Re: [boost] Re: thread lock/unlock example

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

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.

??

- Csaba