SwingWorker and inherited thread priorities

[Sebastian Millies]

There is a potential problem with inherited thread
priorities, described in a recent tech tip from Sun:
http://java.sun.com/developer/JDCTechTips/2005/tt0727.html#1

However, the SwingWorker class (3rd version) described at
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html#SwingWorker
does not contain a call to Thread.setPriority(Thread.NORM_PRIORITY);

I assume this is a mistake (or the problem wasn't known
when SwingWorker was last revised.) Is that right? Stylistically,
should I place the missing statement in the SwingWorker()
constructor where the thread is created, or in the start()
method, where it is started?

-- Sebastian

 

[Sebastian Millies]

Sebastian Millies wrote on Mon, 12 Sep 2005 13:24:32 +0200:

There is a potential problem with inherited thread
priorities, described in a recent tech tip from Sun:
http://java.sun.com/developer/JDCTechTips/2005/tt0727.html#1

However, the SwingWorker class (3rd version) described at
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html#SwingWorker
does not contain a call to Thread.setPriority(Thread.NORM_PRIORITY);

I assume this is a mistake (or the problem wasn't known
when SwingWorker was last revised.) Is that right? Stylistically,
should I place the missing statement in the SwingWorker()
constructor where the thread is created, or in the start()
method, where it is started?

-- Sebastian

OK, to answer my own question: I think there should be call
to Thread.setPriority(Thread.NORM_PRIORITY) in the constructor.
That way, SwingWorker won't create high priority threads by
default, and we allow for a method setThreadPriority(int priority)
to set thread priorities from the outside after creating the
worker.

-- Sebastian
API.

 

[jan V]

OK, to answer my own question: I think there should be call

to Thread.setPriority(Thread.NORM_PRIORITY) in the constructor.
That way, SwingWorker won't create high priority threads by
default, and we allow for a method setThreadPriority(int priority)
to set thread priorities from the outside after creating the
worker.

Unless Sun have moved the goal posts on this subject, it used to be the
established conclusion that to rely on priorities would lead to
platform-dependent problems (bugs, freezes, ..). Many, many years ago there
was an O'Reilly book called "Java Threads" which explained this in great
detail. The authors' solution was to write things which did not rely on any
priority fiddling. In all my years of Java programming I've never altered
any thread priority, and many of my projects have involved multiple threads.
YMMV.

 

[Sebastian Millies]

jan V wrote on Mon, 12 Sep 2005 12:17:39 GMT:

Unless Sun have moved the goal posts on this subject, it used to be the
established conclusion that to rely on priorities would lead to
platform-dependent problems (bugs, freezes, ..).
[...]

Perhaps they have moved the posts - at least in the tech tip to be found
at http://java.sun.com/developer/JDCTechTips/2005/tt0727.html#1
they describe one situation where they recommend changing the thread
priority.
-- Sebastian

 

[jan V]

Unless Sun have moved the goal posts on this subject, it used to be the

established conclusion that to rely on priorities would lead to
platform-dependent problems (bugs, freezes, ..).
[...]

Perhaps they have moved the posts - at least in the tech tip to be found
at http://java.sun.com/developer/JDCTechTips/2005/tt0727.html#1
they describe one situation where they recommend changing the thread
priority.

Thanks for the reference. Another possibility is that, over the years, Sun
has started to suffer from a common problem with large projects (such as
maintaining and evolving the JDK): that one sub-team doesn't know the best
practice and/or rules of thumb employed by another sub-team. This problem is
very self-evident when you analyse any of the "modern" JDKs (say all those
from 1.2 onwards): the quality of design and documentation is far from
uniform.

 

[Thomas Hawtin]

Unless Sun have moved the goal posts on this subject, it used to be the
established conclusion that to rely on priorities would lead to
platform-dependent problems (bugs, freezes, ..). Many, many years ago there
was an O'Reilly book called "Java Threads" which explained this in great
detail. The authors' solution was to write things which did not rely on any
priority fiddling. In all my years of Java programming I've never altered
any thread priority, and many of my projects have involved multiple threads.
YMMV.

It's a quality of implementation matter. You would really like your GUI
thread to take priority to make it responsive. A good JRE on a good OS
will honour the request and give the end user the best possible experience.

You may take it upon yourself to request the worker thread to pause
while the GUI thread is executing. Probably via AWTEventListeners.
However this will have some overhead, make your code more complex and
give an inferior result on a good JRE and OS.

OTOH, I haven't seen much written about throttling updates.

Tom Hawtin