Re: [boost] Boost.Threads Locking Delima

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-17 09:24:08

----- Original Message -----
From: "Darryl Green" <green_at_[hidden]>

Very good description of the problems and compelling arguments.  Let me
focus on a few things, though.

> The ability to lock and unlock in different scopes is required to
implement
> a lockingptr<>. The direct approach being the "hack" which makes accessing
> the mutex lock/unlock possible but _obscure_. Your concern with this seems
> to be that the resulting interface, while obscure, is available for
misuse.

That's the biggest concern, yes.  The other concern is in how to implement
an interface for this that's usable but "obscure".  I'm just not sure I like
the directions we were going in before since I don't feel the interfaces
were "obscure", and the only ones I've toyed with that would discourage
misuse do so not through obscurity but through the fact that it's more
difficult to use then the preferred ScopedLock.

> You propose auto_ptr<> semantics as a solution while noting that there is
> ample evidence that auto_ptr<> can be (and is) misused. However, while it
is
> awfully easily to casually/accidentally misuse autoptr, this wouldn't be
so
> much the case if pointers were not such a common parameter type in C/C++.
> The same can hardly be said for locks, so this mitigates the concerns
about
> accidental invalidation significantly. Of course, if my assertion is right
> and locks are not often passed as parameters, does such a facility belong
in
> the library? The dangers of providing the facility are that it may
encourage
> passing locks (it would seem better to discourage it) and that it will
hide
> errors that would have been detected due to the noncopyable semantics of
the
> current ScopedLock.

Then how about a variation on the auto_ptr interface.  Instead of using the
same syntax for "move semantics" as you would for "copy semantics" the
ScopedLock can provide a "move" operation that returns a proxy for which
another ScopedLock may be constructed from.  So this:

ScopedLock lock1(mutex);
ScopedLock lock2(lock1);

would be illegal while this:

ScopedLock lock1(mutex);
ScopedLock lock2(lock1.move());

would provide auto_ptr like move semantics.  If we choose the right name for
"move" this could discourage users from "passing locks" unless it's needed
and the code is self documenting exactly what's occuring, unlike the syntax
for auto_ptr move semantics.  Would this be more pallatable?  (If so, I
still question whether or not this totally resolves issues with needing
lock/unlock in different "scopes").

> Transferring ownership of a lock seems like something that should only be
> done after some thought and with care. I don't think the care and though
> required to do this using an exposed lock() unlock() interface to a mutex
is
> significantly higher than that required to do it using the
> MoveOwnershipLock.

Do you feel the same with the above syntax?

> The lockingptr<> example is a good example of where it is
> appropriate to lock and unlock in different scopes but (as I see it)
doesn't
> really make much of a case for the MoveOwnershipLock. The wrapping pattern
> is a pattern for precisely the sort of before and after processing that
> locking requires. It is blindingly obvious where/when the mutex should be
> locked/unlocked when implementing this pattern - auto_ptr semantics seem
to
> obscure this rather than making it clearer.

Do you feel the same with the above syntax?

> Unless there are some good things, I think the best that can be done is to
> require a conscious decision and a "statement of intent" in the code
before
> accessing the lock/unlock interface on a mutex.

Does the above syntax work for you in this regard?  If not, do you have any
thoughts on how else to expose this?

Bill Kempf