<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Luke,<br>
In one of those fantastic moments of AHA at 3am this morning, I
perhaps struck mental gold. Instead of using synchronized blocks to
protect thread access, why not just make the the finalizer proxy the
delete request over to the Swing thread. Now you are single threaded
again with no sync blocks or performance hits. I spent a few minutes
this morning working up how a solution might look and am attaching 3
files. Notes on what I did here:<br>
<br>
<ul>
<li>Apparently since I didn't get enough sleep, I modified the 5.4.2
source instead of head. Sorry. It compiles but I didn't try it
because it needs a change to the native side.<br>
</li>
<li>Since the vtkObjectBase is gone and finalized, I had to modify
the VTKDelete native call to be static and take the vtkID as a
parameter. This is the change needed in the native code.<br>
</li>
<li>There is another bug I've found. What is happening is that
nothing is ever removed from the global hash, but the c++ memory
locations used as a key can be re-used once objects are deleted. This
manifests itself as a ClassCastException as the wrong java object is
pulled out of the hash. My attached code corrects this by removing the
Java object from the hash on Delete.</li>
<li>I modified Delete() so that calling it multiple times is safe.
This can make manually deleting objects safer and easier. I'm not tied
to this change, though I think it is a good one. <br>
</li>
<li>Lastly, simply calling SwingUtilities.invokeLater() would
actually do the wrong thing in my application, which uses a separate
ThreadGroup and Swing Event Dispatch thread. So I put a hook in that
allows me to override the default behavior. The average won't even
know this exists, so it should be benign.</li>
</ul>
<br>
Nathan<br>
<br>
Luke Dodd escribió:
<blockquote
cite="mid:e90258f70912171813ybdff6f3h82f4d354991f29ef@mail.gmail.com"
type="cite">
<pre wrap="">It would be good to hear more about the issues you are having, because
it sounds like they could well impact me. (I'm bulding a fairly heavy
swing app)
If indeed any multithreaded access to vtk code, be it mutex locked or
not, turns out to be a problem there are certainly ways round it.
On the simplest level we could keep the code as it is with my added
lock and have the finalizer warn you if it objects it's called on are
not yet deleted by the user. Then perhaps we could add the
vtkGCContext idea you had. Or... we could periodically sweep through
the vtkWeakGlobalRef map and look for entries that have become null
(i.e. garbage collected) and then call delete on them, this could be
done from whatever thread we wanted and have the advantage of not
forcing the user to manage memory (then we could eliminate the global
lock too, although we would still have to be careful). I could look
into these, but right now I have not actually found it to be an issue
so it would be great if you could isolate an example case (I know this
can be very fiddly to do with this sort of code.)
It's no problem working on this - if I manage to nip any threading
problems in the bud before they rear there heads then I'll be happy!
Luke.
2009/12/18 Nathan P Sharp <a class="moz-txt-link-rfc2396E" href="mailto:vtkusers@nps.parcellsharp.net"><vtkusers@nps.parcellsharp.net></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Luke Dodd escribió:
</pre>
<blockquote type="cite">
<pre wrap="">As far as threading problems are concerned I would have thought a
global lock would fix things. It does not really matter what thread
any code gets called from as long as there is not more than one thread
messing around with non thread safe code.
</pre>
</blockquote>
<pre wrap="">This is entirely true for code you write. However, when you start
dealing with hardware acceleration and heavy packages like Swing, OpenGL
and MFC it'll get you in trouble. Those packages all have very specific
rules about what you are and are not allowed to do and often use thread
local storage. In particular OpenGL is tricky because most of it is
implemented in drivers by the hardware vendors. So what works on my box
might crash rapidly on someone else's hardware, even for the same OS.
<a class="moz-txt-link-freetext" href="http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html">http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html</a>
I'm frantically trying to get everything I need done before I go on
vacation next week. It might take me a while but I'll get back to you
on the sample code for the memory leak. I agree that it sounds like an
unrelated problem. Again, thanks for working with me. I look forward
to trying out the sync code.
Nathan
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>