Java Concurrency in practice Chapter 9 GUI Applications

Transcription

1 Java Concurrency in practice Chapter 9 GUI Applications INF329 Spring 2007 Presented by Stian and Eirik 1

2 Chapter 9 GUI Applications GUI applications have their own peculiar threading issues To maintain safety, certain tasks must run in Swing event thread Long-running tasks in event thread =>UI become unresponsive Swing data structures not thread-safe 2

3 Chapter 9 GUI Applications Nearly all GUI toolkits, single-threaded subsystems All GUI activity confined to one thread Usual some activities run partially in an application thread and partially in event thread Even though the GUI frameworks themselves are single-threaded subsystems, application may not be Need to consider threading issues carefully when writing GUI code 3

4 Why are GUIs Single-threaded? Old days GUI applications were single-threaded GUI events were processed from "main event loop" Modern GUI frameworks only slightly different Create a dedicated event dispatch thread for handling GUI events 4

5 Why are GUIs Single-threaded? Have been many attempts to write multithreaded GUI frameworks Problems with race conditions Deadlocks Actions initiated by user tend to "bubble up" from OS A mouse click detected by OS Turned into "mouse click" event by toolkit Delivered to application listener as higher level event such as a "button pressed" event 5

6 Why are GUIs Single-threaded? Almost all GUI frameworks eventually arrived at the single-threaded event queue model Dedicated thread fetches events off a queue Dispatches fetched events to applicationdefined event handlers 6

7 Why are GUIs Single-threaded? Factoring user interactions into cooperating model, view, and controller objects greatly simplifies implementing GUI applications MVC pattern leads to deadlock in multithreaded GUI applications Raises risk of inconsistent lock ordering E.g. Controller calls model Model notifies view - something has changed Controller might also call view View may call back into model to query the model state => inconsistent lock ordering => attendant risk of deadlock 7

8 Why are GUIs Single-threaded? Single-threaded GUI frameworks achieve thread safety via thread confinement All GUI objects accessed exclusively from event thread Pushes some of the thread safety burden back onto the application developer Developer must make sure these objects are properly confined 8

9 Sequential Event Processing GUI applications are oriented around processing fine-grained events such as mouse clicks, key presses, or timer expirations Events are a kind of task The event handling machinery provided by AWT and Swing is structurally similar to an Executor 9

10 Sequential Event Processing Single thread for processing GUI tasks Tasks processed sequentially One task finishes before the next begins No two tasks overlap No need to worry about interference from other tasks 10

11 Sequential Event Processing If a task takes a long time to execute, other tasks must wait until its done If waiting tasks responsible for responding to user input or visual feedback =>application appear frozen Tasks that execute in the event thread must return control to the event thread quickly Long-running task must run in another thread To update a progress indicator while a long-running task executes or provide visual feedback when it completes, code in event thread must be executed Quickly getting complicated 11

12 Thread confinement in Swing All Swing components and data model objects are confined to event thread => any code that accesses these objects must run in event thread GUI objects are kept consistent by thread confinement,not by synchronization Tasks that run in the event thread don t need to worry about synchronization when accessing presentation objects Presentation objects cannot be accessed from outside the event thread at all 12

13 Thread confinement in Swing The Swing single-thread rule: Swing components and models should be created, modified, and queried only from the event-dispatching thread.. Exist a few exceptions See SwingUtilities 13

14 Short-running GUI tasks For simple, short-running tasks, the entire action can stay in the event thread For longer-running tasks, some of the processing should be offloaded to another thread Example on short running task: a button whose color changes randomly when pressed 14

15 Short-running GUI tasks Rule: As long as tasks are short-lived and access only GUI objects (or other threadconfined or thread-safe application objects), you can almost totally ignore threading concerns and do everything from the event thread, and the right thing happens.. 15

16 Short-running GUI tasks - MVC Swing splits most visual components into two objects - model and view Data to be displayed resides in the model Rules governing how it is displayed reside in the view Model objects can fire events indicating that model data has changed Views subscribe to the events View receives event indicating model data may have changed Queries model for new data Updates display Control never leaves event thread 16

17 Long-running GUI tasks If all tasks were short-running Entire application could run within event thread No need to pay any attention to threads at all Normally, GUI applications may execute tasks that may take longer than the user is willing to wait spell checking background compilation fetching remote resources etc 17

18 Long-running GUI tasks Rule: Long-running tasks must run in another thread so the GUI remains responsive to user while they run.. In Swing: Easy to have a task run in event thread Doesn't provide any mechanism for helping GUI tasks execute code in other threads Solution: Create own Executor for processing long-running tasks e.g. a cached thread pool 18

19 Long-running GUI tasks Getting long-running task out of event thread in a "fire and forget" manner Usually visual feedback when a longrunning task completes Cannot access presentation objects from background thread 19

20 Long-running GUI tasks Completion the task must submit another task to run in the event thread to update the user interface Example: Action listener first dims the button Sets a label indicating that a computation is in progress Submits a task to the background executor When that task finishes, it queues another task to run in the event thread Reenables the button Restores the label text 20

21 Long-running GUI tasks 21

22 Cancellation Rule: Any task that takes long enough to run in another thread probably also takes long enough that the user might want to cancel it.. Could implement cancellation directly using thread interruption Easier to use Future Designed to manage cancellable tasks 22

23 Cancellation 23

24 Cancellation RunningTask is confined to event thread No synchronization is required when setting or checking it StartButton listener ensures only one background task running at a time Better to be notified when task completes E.g. cancel button could be disabled 24

25 Progress and completion indication Using a Future to represent long-running task simplifies implementing cancellation FutureTask also has a done hook that similarly facilitates completion notification When background Callable completes => done called Done trigger a completion task in event thread Construct a BackgroundTask class providing an oncompletion hook thats called in event thread See example class BackgroundTask 25

26 SwingWorker Techniques showed in FutureTask and Executor examples can be applied to any single-threaded GUI framework In Swing, many of the features developed in the examples are provided by the SwingWorker class Various versions of SwingWorker have been published in The Swing Connection and The Java Tutorial Updated version is included in Java 6 26

27 Shared data models Swing presentation objects, including data model objects, are confined to the event thread In simple GUI programs All mutable state held in presentation objects Only thread beside event thread is main thread Enforcing single-thread rule easy: don't access data model or presentation components from main thread More complicated programs May use other threads to move data to or from a persistent store, e.g. file system or database 27

28 Shared data models In simplest case, data in the data model: Entered by the user Loaded statically from file / other data source at application startup Never touched by any thread other than event thread Sometimes presentation model object is only a view onto another data source, e.g. database, file system, or remote service. More than one thread is likely to touch the data as it goes into or out of the application. 28

29 Shared data models E.g. display content of remote file system using a tree control Enumerate entire file system before displaying tree control Takes much time and memory Enumerating a single directory on a remote volume can take long time Tree can be lazily populated as nodes are expanded Enumeration in a background task When background task completes Push data from background task to event thread by posting a task with invokelater Have event thread poll to see if the data is available 29

30 Shared data models Initiating a long-running, cancellable task with BackgroundTask 30

31 Thread-safe data models Responsiveness not unduly affected by blocking Problem of multiple threads operating on data can be addressed with a thread-safe data model If data model supports fine-grained concurrency, event thread and background threads should be able to share it Thread-safe data models must generate events when the model has been updated => Views can be updated when the data changes 31

32 Thread-safe data models Sometimes possible to get thread safety, consistency and good responsiveness with a versioned data model as CopyOnWriteArrayList When acquirering iterator for a CopyOnWrite collection, iterator traverses collection as it existed when the iterator was created CopyOnWrite collections offer good performance only when traversals greatly outnumber modifications Building versioned data structures that provide efficient concurrent access and not retain old versions of data longer than needed is not easy32

33 Split data models Swing table model classes like TableModel and TreeModel are the official repository for data to be displayed Model objects are often themselves "views" of other objects managed by the application A program that has both a presentation-domain and an applicationdomain data model is said to have a split-model design 33

34 Split data models Presentation model is confined to the event thread and the shared model Shared model thread-safe May be accessed by event thread and application threads Presentation model registers listeners with shared model Can be notified of updates Presentation model can be updated from shared model Retrieve data directly from shared model 34

35 Other Forms of Single-threaded Subsystems Thread confinement not restricted to GUI`s Can be used whenever a facility is implemented as a single-threaded subsystem Sometimes thread confinement is forced on the developer for reasons that have nothing to do with avoiding synchronization or deadlock Some native libraries require all access to the library, even loading the library with System.loadLibrary, is made from the same thread 35

36 Summary GUI frameworks are nearly always implemented as single-threaded subsystems All presentation-related code runs as tasks in an event thread. Long-running tasks can compromise responsiveness Should be executed in background threads Helper classes can simplify development of long-running tasks that have both GUI and non- GUI components 36