2009/5/12 Mark Taylor <[log in to unmask]>:
> On Tue, 12 May 2009, Peter W. Draper wrote:
>
>> On Tue, 12 May 2009, Mark Taylor wrote:
>>
>> > On Tue, 12 May 2009, David Berry wrote:
>> >
>> > > Mark,
>> > > Did any of your JNIAST threading tests demonstrate this
>> > > deadlock problem, or was it just splat that tripped over it?
>> >
>> > no, I don't believe I ever wrote a unit test that showed this,
>> > at least not consistently.
>>
>> Not surprised about that. To reproduce what SPLAT was up to when the locking
>> mismatches were seen you'd need to be doing something with a complex AST
>> Frameset in one thread and then trigger another thread to also access the same
>> Frameset, cache some clones, and then do that a lot until the deadlock finally
>> triggered, maybe.
>>
>> In SPLAT this seems to happen as I read in data files in one thread, meanwhile
>> the UI thread can receive an event that causes it to start drawing the same
>> spectra. It's somewhat worse than that as well, as the plot FrameSets are also
>> involved, having references to parts of the data Framesets as well...
>
> I probably could write a unit test that showed it up (some of my
> JSAMP unit tests use several tens of threads...), but I don't think I
> tried because at the time I didn't see much chance of getting
> it fixed.
Tim/Frossie may be more inclined to allocating me some time to fix it
if it looks like it could possibly be a problem for smurf. In which
case, having some means of telling whether I have in fact fixed it
would be V. useful.
David
|