[boost] Re: Boost.Threads Locking Delima (William E. Kempf)

From: Eric D Crahen (crahen_at_[hidden])
Date: 2002-05-17 17:59:07

> > The main thing is that there is only one scope that is controlling the
> > lifetime, unless there is a way for a Proxy to outlive the GuardedObject
> > that I'm missing.

> No, there are two scopes.  In Bjarne's implementation the scopes are
> operator->() (for lock) and the Proxy (for unlock), while in yours they
> are Proxy instance 1 (the constructed object in operator->(), for lock)
> and Proxy instance 2 (the temporary returned from operator->(), for
> unlock).

I mean that the lock is owned, created and destroyed by the GuardedObject
only. That's the important scope I was talking about. There aren't any
ownership issues because the GuardedObject will always own the lock and
outlive the proxies. The proxy extends the ScopedLock (Guard) so there is
no need to expose the underlying mutex (any ownership things can be dealt
with by the ScopedLock with a policy). (I think this was just me missuing
the term scope for this, I should be more specific)

I was also thinking a little bit about where you'd use this. The example
I mentioned about making a thread safe wrapper with it is not as useful
as I first thought either. For example, that won't safely work for any STL
collection, iterators can't be synchronized with this way. This would
only work for simple objects. You run into a whole other problems of
trying to somehow also create wrappers around the objects being returned,
its a mess.

Does anyone have a real world example of where you would want to pass lock
references around? I always keep locks encapulated within the classes
they are controlling access in. When doing this, using a ScopedLock is
sufficent, one the supports nested and overlapping scopes is better.

I've never had a need a reason to expose locks like this, so I'm finding it
difficult to relate to this. The only example the wrapper paper provides
is creating a simple wrapper for sychronized acess, but I think that is
limited in usefulness anyway (deadlock potential and braod granularity of
locks - I'm very intrested in seeing someones opinion about these issues,
or if they have a way to deal with them).

- Eric
http://www.cse.buffalo.edu/~crahen