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. So should it just
unlock the FrameSet and leave the Frame unchanged, or should it
generate an error? Even if it did the former, an error would be
reported when another thread attempts to lock the FrameSet. So you get
an error either way.
David
If the first thread then attempts to unlock the FrameSet
2009/2/19 Mark Taylor <[log in to unmask]>:
> On Thu, 19 Feb 2009, David Berry wrote:
>
>> 2009/2/19 Mark Taylor <[log in to unmask]>:
>> > On Thu, 19 Feb 2009, Peter W. Draper wrote:
>> >
>> >> Hi Mark,
>> >>
>> >> seems there is a problem when I load and display several spectra at the same
>> >> time:
>> >
>> > oh dear.
>> >
>> >> [java] uk.ac.starlink.ast.AstException: AST: Error at line 316 in file
>> >> jniast.c.
>> >> [java] astUnlock(FrameSet): Failed to unlock the FrameSet because a
>> >> CmpFrame contained within it is locked by another thread (programming
>> >> error). (null)
>> >
>> > David, can you comment on what circumstances would lead to this error?
>> > I don't think I realised that an astUnlock() could generate an error.
>> > If the "programming error" mentioned in the message is at the application
>> > level, what steps ought one to take to avoid it happening? If it's
>> > at the library level, over to you...
>>
>> It's prompting the application writer to ask why an attempt is being
>> made to unlock an Object that is currently locked by another thread.
>> It suggests that the thread doing the unlocking erroneously believes
>> itself to have the object locked for its own use - otherwise, why
>> would it be trying to unlock it?
>
> Since the astUnlock() documentation says "This function returns without
> action if the Object is not currently locked by the calling thread",
> it sounded to me like astUnlock on an unlocked object was permissible.
>
> However, it sounds like it's not as simple as that, since lockedness
> is not a binary property - an object can be locked, or unlocked,
> or unlocked but with some locked constituents. Calling astUnlock(obj)
> has the following effects:
>
> obj is locked: becomes unlocked
> obj is unlocked: no effect
> obj is partially locked: error
>
> Is this error message generated (a) because AST actually can't relinquish
> a given thread's hold on a partially locked object for some reason, or
> (b) just because it feels that such things shouldn't be encouraged and
> the author should be made to think twice about it?
>
> If (b) then for consistency I'd expect it to fail when called on a
> totally unlocked object as well.
>
> If (a) maybe I can solve the problem by every time I want to unlock an
> object which might be a bit locked, I precede the astUnlock(obj)
> with an astLock(obj,1). Do you think that would work? (also, is
> it likely to be expensive, given that I'm locking/unlocking everything
> every time I use it?)
>
> I'm not sure yet whether I am deliberately unlocking things which I
> haven't previously locked. At first glance I don't think so, which
> suggests that there's some subtlety about constituent objects getting
> locked in an unpredictable way independently of their owner objects -
> but I'd need to investigate further to check that out.
>
> Mark
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> [log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>
|