On Fri, 20 Feb 2009, David Berry wrote:

> 2009/2/19 Mark Taylor <[log in to unmask]>:
> > On Thu, 19 Feb 2009, David Berry wrote:
> >
> >> Yes, there is a point here that it's pretty easy to end up with
> >> partially locked objects. Say a thread creates a Frame, then creates a
> >> FrameSet containing the Frame, then unlocks the original Frame and
> >> passes it to another thread that locks it. The FrameSet itself is then
> >> still  locked by the first thread, but the Frame within it is locked
> >> by the second thread. If the first thread then attempts to unlock the
> >> FrameSet what should happen? It cannot unlock the Frame within the
> >> FrameSet because it is locked by another thread.
> >
> > The semantics I expect if thread T calls astUnlock on object A
> > is that T unilaterally relinquishes claims on A.  That is,
> > I don't expect astUnlock to guarantee that an object is not
> > locked by anybody, but only that it is not locked by the calling thread.
> > Seen like this, there's no reason (I think) that astUnlock can't
> > be implemented in such a way as to recurse through all objects
> > contained in the one which is unlocked, and (I think) that's what
> > I'd expect to happen.
> 
> I can see that this approach could be a reasonable way of handling
> objects contained within other objects, but I'm a bit hesitant about
> applying this idea to top level objects. Surely each thread should
> know what top-level objects it has locked for itself, and so why would
> it want to unlock an object that is currently locked by another
> thread, except as the result of a prgramming error?  On the other
> hand, whilst a thread could reasonably be expected to know what
> top-level objects it currently owns, I can see it may not necessarily
> know much about any objects contained within those top-level objects.
> 
> So what about reporting an error if the top-level object supplied to
> astUnlock is currently locked by another thread, but silently ignoring
> any sub-objects that are locked by other threads?

I'm not sure that's an improvement on my suggestion (additional 
complication in the interface from distinction between top-level 
and contained objects; possibility of requiring more bookkeeping 
from calling code e.g. in try/catch/finally type patterns), however, 
I'm happy for you to implement it like this.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/