Re: invokeLater and weird race conditions in my swing app
apm35@student.open.ac.uk wrote:
Hello,
I have a swing app that needs to read from a database when building
some of its dialog windows and when updating rows in its JTable
components. My app seems to be suffering from race conditions.
Apparantly randomly it hangs when updating a data model for my JTable.
I have a trace stmt before and after the call to mode.insertRow. The
first trace gets executed, the second does not.
I'm surprised it hangs. I would not expect this, unless you are performing some
sort of synchronization yourself which is causing the hang. I am not aware of
any internal locking within JTable or TableModel which could result in a hang.
I have discussed this with a colleague who suggest that I use the
function invokeLater to send any swing work to the swing event
dispatching thread. I will look into this but I am puzzled. My app
does not start such a thread explicitly so I wonder how it does get
started. Also, why dont the swing functions do this work anyway? I am
an ex-Motif programmer and from my Motif days I remember that all the
Motif and X11 calls do not render directly - they write a message to
the X11 server which will do the rendering upon rcpt of the message. I
assumed that swing would have a similar design but done using threads
within the app (my main thread making the swing call which would send
the request to the swing event message processing thread). So I
suppose it doesnt work like that then.
The EDT is started by the JVM when you realize the first GUI component. From
this time forward all modifications to the GUI should be handled by the EDT.
Using SwingUtilities.invokeLater() is one way of doing this. [There are a few
exceptions in that you are allowed to invoke some methods of some components
from other threads, but it's simplest if you treat all methods of all Swing
components as non thread-safe.] I think the reason Swing does this is that if
the components were made thread safe by internal locking the GUI interface
might well respond too slowly. So they are not locked, and the single-thread
rule must be obeyed.
IIRC X/Motif is (or at least it was) inherently single-threaded. I have some
vague and unpleasant memories of programming X/Motif in C with Solaris threads.
In a similar way to Swing/EDT, because X/Motif was single-threaded, only 1
thread could access the Motif widgets unless you synchronized/locked every
access, but locking every access resulted in a GUI which was slow and
unresponsive. So, it was necessary to program 1 thread to receive
information/events from the other threads, then act on that information. At
least Java/Swing provides these mechanisms for you, you just have to know the
restrictions and stick to the rules.
Since some of the work my app is doing is database-related this bit
can be slow so maybe this is why things get into a mess. Can any swing
gurus comment on this please?
If you are using Java 1.6 then look at the SwingWorker class. This ought to be
able to do what you require. Also, read the tutorial on "Creating a GUI with
JFC/Swing" at http://java.sun.com/docs/books/tutorial/uiswing/TOC.html, in
particular the section on How to Use Tables. This could provide you with some
valuable assistance.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555