CSC 480 - Multiprocessor Programming, Spring, 2012 Chapter 9 – GUI Applications Dr. Dale E. Parson, week 11

Event Dispatch Thread GUI Events (user, timer etc.) occur in a GUI event dispatch thread. Method calls among Swing GUI objects must occur confined to this thread. No other thread my directly invoke methods on these GUI objects. The event dispatch thread should not invoke long-running computations outside the GUI. The user interface becomes unresponsive.

Multithreaded GUI Attempts User actions bubble up from the O.S. Application actions bubble down to the O.S., e.g., to repaint a display. Resulting cycles in lock dependencies on thread-sage GUI components tends toward deadlock. Model-view-controller (MVC) pattern can suffer from the same problem. controller -> model -> view (model events paint view) controller -> view -> model (view queries model)

Thread Confinement for GUIs GUI events and updates are sequential. Burden of thread confinement is placed on application programmer. GUI components must be confined inside an encapsulated class or set of classes to maintain thread confinement. Simpler thread confinement to local variables and parameters is not possible because GUI components must outlive the call stack frames that construct them. GUI library must have hooks for interacting with other threads.

Thread confinement in Swing SwingUtilities.isEventDispatchThread Is the current thread the AWT dispatch thread? SwingUtilities.invokeLater Invoke a Runnable on AWT dispatch thread after all pending events. invokeAndWait blocks until Runnable completes. Enqueuing repaint or revalidation request on the event queue can occur on any thread. Adding and removing event listeners can occur on any thread.

Simplest case Event responses either stay in GUI or interact with application objects using short-lived method invocations that are single-threaded or thread safe. Fast methods, no entry of other threads into GUI. GUI update can occur as a result of a change in an MVC model such as a TableModel (javax.swing.table) or TreeModel. Control must not leave the event thread.

Long running GUI tasks These must run in another thread. A cached thread pool is a good choice. User-initiated tasks normally do not grow in number unmanageably. A SingleThreadExecutor is good if you want to limit application concurrency without stalling the GUI. Only one application task runs at a time, but the GUI remains available for interrupting the task. On completion a task must submit a task on the dispatch thread (a Runnable) to update the UI.

Cancellation The user may want to abort a long running task from the GUI. You can interrupt the task directly, but … Submitting a task in an ExecutorService and then cancelling its Future, if necessary, is more organized. Set cancel’s mayInterruptIfRunning to true. Write task code to respond to interrupts.

SwingWorker javax.swing.SwingWorker is an abstract class (scaffolding) for building long-running computations driven from the GUI thread. It implements Runnable, Future<T>, and RunnableFuture<T>. Abstract method doInBackground runs in a background thread, returns T on completion. An application supplies this method, and SwingWorker takes care of propagating the result to the GUI thread.

Shared MVC models TableModel or TreeModel must update the View (GUI) on the dispatch thread. How to get results from another thread into the model? Use a thread-safe implementation of interface TableModel or TreeModel. Push data from the background task to the event thread via invokeLater, where the invoked Runnable updates the model. Let the event thread poll periodically for data from the worker thread.

Split data models A data model with both a presentation domain and an application domain is a split model design. Presentation model is confined to the event thread. Shared model is thread-safe and may be accessed by both the event thread and application threads. Presentation model registers listeners so it can be notified of updates. Event thread updates GUI with a snapshot of the model. Works best with small, infrequently updated model. If models is large or updates occur frequently, incremental updates of the mutations only (as opposed to complete snapshots) may be more efficient.

Split model, native code classes Consider a split-model design when a data model must be shared by more than one thread and implementing a thread-safe data model would be inadvisable because of blocking, consistency, or complexity reasons. Some native code libraries require all accesses to the library to be made by a single thread.