0% found this document useful (0 votes)
114 views

JavaFx Thread

This document discusses multithreading concepts in JavaFX, including: - Synchronizing access to shared data using the "synchronized" keyword to prevent race conditions. - Using wait() and notify() to coordinate threads when one must wait for a condition change made by another. - Preferring concurrency utilities over direct use of wait() and notify(). - The threads involved in a JavaFX application - the application thread for UI updates, a render thread, and media thread.

Uploaded by

RichieOni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
114 views

JavaFx Thread

This document discusses multithreading concepts in JavaFX, including: - Synchronizing access to shared data using the "synchronized" keyword to prevent race conditions. - Using wait() and notify() to coordinate threads when one must wait for a condition change made by another. - Preferring concurrency utilities over direct use of wait() and notify(). - The threads involved in a JavaFX application - the application thread for UI updates, a render thread, and media thread.

Uploaded by

RichieOni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Multithreading in JavaFX

10-30-2013
 Multithreading in JavaFX (javafx.concurrent)

Read:
 Java Tutorial on concurrency
 JavaFX Tutorial on concurrency
 Effective Java, Chapter 9
Project#1: due today

return and discuss Exam#1


Exam#2 is scheduled for Tuesday, Nov. 19, 7:00 pm,
in Snell 213
 Two or more threads sharing an array of account
data attempt to read/write the data
Note that: accounts[to] += amount;
is not an atomic operation:
load accounts[to] in some register
add amount to that register
save the register in accounts[to]
 Solution: keyword “synchronized”
public synchronized void transfer(int from, int to, int amt)
public synchronized void test()
Note: not all methods need to be synchronized (e.g. size() )
 One thread examines the state of the
system and needs to wait until a certain
condition is true
 e.g. insufficient funds in an account
 wait() method
 A different running thread changes the
state of the system and needs to wake-up
threads that are waiting
 e.g. make deposit in an account
 notify() and notifyAll()
public synchronized void transfer(int from, int to, int amt)
{ only one thread can run this code
try { at a time; all others are delayed
while (accounts[from] < amt)
wait(); currently running thread goes to sleep
accounts[from] -= amt;
accounts[to] += amt;
ntransacts++;
if (ntransacts % NTEST == 0) test();
notifyAll(); running thread wakes up all waiting threads
} catch(InterruptedException e) { … }// handle the exception
} running thread exits synchronized method; JVM wakes up
a thread waiting to run this method (if any)
Effective Java, Chapter 9
Item 48: Synchronize access to shared mutable data
Item 49: Avoid Excessive synchronization
Item 50: Never invoke wait outside a loop
Item 51: Don’t depend on the thread scheduler
Item 52: Document thread safety
Item 66: Synchronize access to shared mutable
data
 “synchronized” code ensures that an object is
only observed when it is in a consistent state
(mutual exclusion)
 “synchronized” code also ensures that when
one thread starts running code in a
synchronized method, it sees all the
modifications to that same object made by
other threads
 Item 69: Prefer concurrency utilities to wait
and notify
// standard idiom for using the wait method
synchronized (obj) {
while (<condition does not hold>)
obj.wait(); // releases lock & re-acquires on wakeup
// continue
}
better to use java.util.concurrent utilities
 a specific object is locked (not a class, not a
method)
 when an object is locked, no other thread may
modify it
 when a thread successfully calls a
synchronized method, it “owns” the lock to
the object until either it returns from the
method, or it calls wait()
 when one thread owns a lock to an object,
other threads can call any method which is
not synchronized; if, however, another thread
calls a synchronized method it is blocked
 when one thread calls wait(), it depends on
another thread to call notify() or notifyAll()
 deadlocks are a serious problem
problem: what if the state values change
while the component is in the process of
painting itself?

problem: performing a long operation on the


event dispatch thread, such as reading or
writing a file, will block the whole UI (no
other event can be dispatched until this
operation completes)
1. Import the pertinent packages
2. Set up a top-level container.
3. Display the container.
4. Be thread-safe.
javax.swing.SwingUtilities.invokeLater(
new Runnable() {
public void run() {
/* code to create and show the GUI */
} // end run
} // end Runnable
); // create and run a thread
 event handlers can be instances of any class
 event handling code executes in a single thread
(Event-Dispatching Thread). This ensures that
each event handler will finish executing before
the next one starts. Painting code also occurs in
the event-dispatching thread, so while the
actionPerformed() is executing, the GUI is frozen
(e.g. can’t be repainted or respond to mouse
clicks)
 event handlers MUST execute very quickly; if only
a few lines of code, can be implemented as an
anonymous class
When a swing application is deployed, there are
three threads created:
 main thread – runs the main program code
 toolkit thread – captures user interaction
 Event Dispatch Thread – EDT

problem: performing a long operation on the EDT,


such as reading or writing a file, will block the
whole UI (no other event can be dispatched until
this operation completes)
e.g. user enters text
e.g. user clicks in text field
on a button
 user presses a key in a text field the event is
created and posted on the Event Queue;
 at some point, the event is selected from the
queue by the EDT and processed by calling the
component’s key listener
 the component updates its model and posts a
paint request on the Event Queue;
 at some point, the EDT selects that off the
queue and notifies the component to repaint
itself
 The EDT is responsible for executing any
method that modifies a component’s state
(including the component’s constructor)
public void actionPerformed(ActionEvent e) {
String text = ReadHugeFile(); // time consuming
// bad code alert!
textArea.setText( text );
}

Problem: Potential Deadlock


Solution: invokeLater
javax.swing.SwingUtilities:
 invokeLater() – posts a new task on the Event
Queue

Note: SwingWorker utility class that simplifies the


creation of long-running tasks that update the
user interface
javax.swing.SwingUtilities.invokeLater(
new Runnable() {
public void run() {
/* create and show the GUI */
} // end run method
} // end Runnable
); // create and run a thread on the EDT
The system runs two or more of the following
threads at any given time.
 JavaFX application thread: This is the primary thread
used by JavaFX application developers. Any “live”
scene, which is a scene that is part of a window, must
be accessed from this thread.
 Prism render thread: This thread handles the
rendering separately from the event dispatcher. It
allows frame N to be rendered while frame N +1 is
being processed.
 Media thread: This thread runs in the background
and synchronizes the latest frames through the scene
graph by using the JavaFX application thread.

You might also like