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

From: Eric D Crahen (crahen_at_[hidden])
Date: 2002-05-17 16:28:48

> > As far as the need to transfer ownership goes, I'm not entirely convinced
> > there is a real need for this. The only use this seems to have is to
> > create a wrapper that provides serialized access to each function on some
> > object right?
>
> No, I doubt that's the only need.  It's just the most obvious real world
> use case availabe to illustrate what's needed.

Does anyone have any other examples? I can see this for wrapping objects
that were never meant to be thread safe; but other than than that, I can't
really think of any decent use for it - it forces a broad lock granularity
on whatever you are using it on, so for complex objects it seems rather
limiting - and using it on objects that are synchronizing internally is
dangerous (deadlock). I think it would be helpful if we have a real
problem to solve, not that this isn't a good problem - just that a
something more material to work with could be useful.

> Eric, your GuardedObject *IS* the same thing as the locking_ptr<> I've
> referred you to.  And your above implementation is flawed.

It was just for demonstration; but the main difference is that locking_ptr
(my GuardedObject) doesn't have to do anything at all with the locks - i'm
just inheriting all that directly from the ScopedLock (my Guard). So all
that needs to be dealt with then is just the operators and other things
not explicitly doing and synchronization. You could probably just use an
ownership policy as some of the others suggested to fix the flaw easily.
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.

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