This is a working page for developing a new threading model.
See the older page, which doesn't say much: http://jmri.sf.net/help/en/html/doc/Technical/Threads.shtml
Reasons/Goals/Concerns
- Some operations take too long, and hang up the user interaction. E.g. opening a programmer panel, or opening a panel file.
- Scripts run from the GUI start in the Swing thread, and can kill it. This needs to change.
- The various automation tools are thread heavy - e.g. right now an AbstractAutomaton, Siglet, etc has a thread of its own. The transitions for those need to be pretty clear.
- Proper use of user and daemon threads is necessary for clean shutdown.
Issues
Dan Boudreau has found that the SwingUtilities.invokeLater can get hung for a long time on an AWT lock. Bad! This hangs the receive or transmit threads in TrafficControllers, in turn causing timeouts. A temporary way around that is to have the TrafficControllers queue their notifications to a new central Thread (call it "JmriEventHandler"), which for now just puts them to Swing.
Paul Bender has found that the Swing EventQueue? can induce delays on messages reaching the appropriate listeners. This can cause timing dependent operations to fail.
New Model
(This is still in progress, both as a web page and as a design, and there is no implementation yet - check with the jmri-developers list!)
Moving to Java 1.5 brings a couple things that will really help:
- SwingWorker, to make it easier to defer GUI-related things. This may make it possible for GUI classes to contain their own transitions from the system threads (e.g. listener calls) to their GUI operations. We need this before we can move most auto operations off the Swing thread.
- java.util.TImer, a non-Swing timer class
- Concurrent collections make it easier to interlock data operations
- Note
- "Interrupted" must be reserved for truly interrupting and killing a thread. That's mostly needed in scripting and scripting support (but see the kill button in the thread monitor)
References
Java theory and practice: Dealing with InterruptedException, from IBM developerWorks.