Re: [boost] Boost.Threads Locking Delima

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

----- Original Message -----
From: "Mattias Flodin" <flodin_at_[hidden]>

> Here's another idea: To gain access to lock() and unlock() function
> you must first create a "lock guard" object which, upon destruction,
> will force the synchronization primitive to be unlocked. This would be
> done in a scope surrounding the critical code. For instance, using
> your code example:
>
> {
> GuardLock g1(m1);
> GuardLock g2(m1);
> g1.lock();
> do_something_to_m1_shared_data();
> g2.lock();
> do_something_to_m1_and_m2_shared_data();
> g1.unlock();
> do_something_to_m2_shared_data();
> g2.unlock();
>
> // If we forgot to unlock anything, it will be unlocked here
> }

This is the current design of the ScopedLock concepts in Boost.Threads.
Nothing new here, and it doesn't solve the second drawback to the
ScopedLocking pattern... where the lock and unlock must occur in truly
seperate "scopes", such as the example given for implementing a
locking_ptr<>.

> Of course, the danger with this is that you may forget to unlock
> something and it will be unlocked eventually, but it will be held
> longer than necessary, thus reducing parallelism (or potentially
> causing a deadlock).
>
> But it seems, on the other hand, that a lock with move semantics would
> have the same problems. With auto_ptr the idea is sort of that "we
> don't have to care about how long this lives, it will be taken care of
> for us." But with locks, knowing the exact lifetime of a lock is
> likely to become more important.

You know the precise lifetime with an auto_ptr.  This is clearly controlled
by the "single ownership" and "transfer of control" semantics specified by
the standard.  You can "extend" the lifetime outside of the initial "scope"
(sorry to keep using quotes, but I'm not quite using the terminology 100%
technically accurate) by using the move semantics to transfer ownership to a
new instance, but the lifetime is still clearly delineated in this case.  So
I'm not sure I see a difference that will cause more problems for a
ScopedLock with move semantics based on the need to know the exact lifetime.

Bill Kempf