JavaFx Thread

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.

JavaFx Thread

Uploaded by

Copyright:

Available Formats

JavaFx Thread

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JavaFx Thread

Uploaded by

Copyright:

Available Formats

Multithreading in JavaFX

return and discuss Exam#1

problem: performing a long operation on the

problem: performing a long operation on the EDT,

Problem: Potential Deadlock

Note: SwingWorker utility class that simplifies the

You might also like