Setting GUI thread priority

Thread view:

FutureScalper - 12 Jan 2008 03:57 GMT

I've successfully interated through threads on windows named AWT-
EventQueue-* and change their priorities. I assume this changes the
execution priority of code running on the GUI thread. Is this a
correct assumption? I need to adjust relative priorities within my
code. So do you think this will actually work to alter the priority
of AWT/Swing GUI tasks?

Reply to this Message

Lew - 12 Jan 2008 04:22 GMT

> I've successfully interated through threads on windows named AWT-
> EventQueue-* and change their priorities. I assume this changes the
> execution priority of code running on the GUI thread. Is this a
> correct assumption? I need to adjust relative priorities within my
> code. So do you think this will actually work to alter the priority
> of AWT/Swing GUI tasks?

It depends on the JVM. There are no hard guarantees about how Java thread
priorities map to OS priorities, even assuming the OS has them.

Generally, however, you can count on a higher-priority thread starting when a
time slice opens.

However, many scheduling algorithms will promote a thread's priority if it
hasn't run in a while. So your low-priority thread might still occasionally
jump in ahead of one with a nominally higher priority.

Priority scheduling in a GUI as you suggest is almost certainly not going to
help. First of all, you do not indicate exactly how you adjust your thread
priorities - it might be that you missed the Event Dispatch Thread (EDT).
More importantly, the focus on thread priority does not mean you are getting
the GUI thread management correct. You still need to move long-running tasks
off the EDT, and absolutely ensure that graphic activity occurs only on the
EDT. You still need to synchronize concurrent data access, although not
necessarily via the "synchronized" keyword. In other words, messing with
priorities adds to your work, but doesn't relieve you of any.

Furthermore, once you do all the right things with tasks off the EDT and
graphics on it, you will have a snappy, responsive GUI without having to deal
with thread priorities.

Which leads to a question, as I am making a huge assumption here. What is
your purpose in adjusting thread priorities in your GUI?

I am asking for the benefit, or the goal here, not a mere description of the
technique. What will thread priority adjustment accomplish in your application?

Signature

Lew

Reply to this Message

FutureScalper - 14 Jan 2008 01:49 GMT

Well, the application is a fast, near real-time Online Futures
Scalping application, so it acquires market data, up to about 10,000
events per minute, analyzes, charts and also manages multiple
simultaneous live orders. It uses a Swing GUI hand-coded, and is
heavily optimized for high performance. A live order is "bumped" in
price to a new price, in roughly 120 milliseconds and so order
processing events are high priority for me.

So, in general, I want order processing threads to be highest in
priority, but there is one area in which I am concerned about high
priority. Maybe I'm wrong, and maybe what I really want is a non-gui
execution of Swing events but, for now, I believe these events execute
on the GUI dispatch thread.

Let's say I want a keystroke or a mouse click to affect order
processing activity. My simple understanding is that these run on the
GUI dispatch thread, which is a reasonable design decision designed to
serialize their activity.

So, I want to elevate/control the execution priority of the GUI
thread, so that these events, which ultimately kick off order entry
actions, are themselves very responsive.

I understand the concerns associated with multiple thread priorities,
and I think I've struck a reasonable balance here.

I don't actually have long-running activities on the GUI thread, so
that's not a concern.

But specifically, this was my reason for wanting to have some control
over the priority of GUI activities. The idea being that a keystroke
or mouse click should run in preference to my lower-priority NON-order
processing threads, because most of these GUI activities are designed
to be responsive in a chain of my highest priority events, which are
live order processing management.

I should add here that I stress the Java Server VM to its limits in
this application, and things are very fast, for a Java application,
that is...

I use practically every switch in the book right now, and this is a
mature application, just so you aren't thinking I'm a Newbie or
something like that.

The application runs roughly 100 threads in a process, and my primary
target platform is Windows XP or Vista using Sun's Server VM.

Server VM Runtime switches are:

<resources>
<j2se version="1.6.0+" java-vm-args=" -server -dsa
-XX:ThreadStackSize=256 -XX:CompileThreshold=50 -XX:+AggressiveOpts -
XX:MaxGCPauseMillis=200
-XX:CICompilerCount=1 -XX:+UseBiasedLocking -XX:+CMSIncrementalMode -
XX:+AggressiveHeap
-XX:+RelaxAccessControlCheck -XX:-TieredCompilation --XX:NewSize=640m -
XX:MaxNewSize=640m -XX:SurvivorRatio=16
-XX:MaxInlineSize=64000 -XX:FreqInlineSize=64000 -XX:-
DontCompileHugeMethods
-XX:+UseFastAccessorMethods -Xss192k -Xms380m -Xmx380m -Xbatch -
Xnoclassgc
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel -
Dswing.metalTheme=steel
-Duser.timezone=America/New_York -Duser.language=en -Duser.region=US"/

> > I've successfully interated through threads on windows named AWT-
> > EventQueue-* and change their priorities. I assume this changes the
[quoted text clipped - 35 lines]
> --
> Lew

Reply to this Message

Lew - 14 Jan 2008 03:00 GMT

> Well, the application is a fast, near real-time Online Futures

Please do not top-post. Use trim-and-inline posting.

> Scalping application, so it acquires market data, up to about 10,000
> events per minute, analyzes, charts and also manages multiple
[quoted text clipped - 8 lines]
> execution of Swing events but, for now, I believe these events execute
> on the GUI dispatch thread.

The Swing events run on the EDT, and must.

> Let's say I want a keystroke or a mouse click to affect order
> processing activity. My simple understanding is that these run on the
> GUI dispatch thread, which is a reasonable design decision designed to
> serialize their activity.

It is necessary by the very innate nature of GUIs.

> So, I want to elevate/control the execution priority of the GUI
> thread, so that these events, which ultimately kick off order entry
> actions, are themselves very responsive.

No, you want to make sure the order entry actions happen at a high priority,
not the GUI events. In fact, you likely do not need to mess with the
priorities at all.

> I understand the concerns associated with multiple thread priorities,
> and I think I've struck a reasonable balance here.

I am not sure that you do, nor that you have.

What other threads are running whose priority you wish to preempt in favor of
the GUI?

> I don't actually have long-running activities on the GUI thread, so
> that's not a concern.

"Long-running" is a relative term. In your case I suspect you'll get more
benefit from updating your model on a non-EDT (possibly high-priority) thread
than by changing the EDT priority.

> But specifically, this was my reason for wanting to have some control
> over the priority of GUI activities. The idea being that a keystroke
> or mouse click should run in preference to my lower-priority NON-order
> processing threads, because most of these GUI activities are designed

What are these other threads? Do they influence the GUI?

> to be responsive in a chain of my highest priority events, which are
> live order processing management.

So run the model that changes prices at a higher priority. Your GUI happens
for all logic, not just the priority logic, all in the EDT - one thread for
GUI service to all other non-GUI threads.

You should make the high-priority /logic/ higher priority, not the GUI.

> I should add here that I stress the Java Server VM to its limits in
> this application, and things are very fast, for a Java application,
[quoted text clipped - 24 lines]
> Dswing.metalTheme=steel
> -Duser.timezone=America/New_York -Duser.language=en -Duser.region=US"/

I just don't think it's the EDT priority that should concern you. Of course I
don't really know, but do not be surprised if playing with the EDT priority
fails to help very much. If your model updates fast enough you might find
that the GUI can keep up without having to mess with priority.

In other words, be sure to test your assumptions before deploying them into
production.

For one thing, if you boost the EDT priority, it boosts for *all* GUI events,
not just the ones associated with your price changes. Instead, boost the
priority of the threads that actually handle the order price changes.

If you really want faster, switch from Vista to Linux or Solaris. Consider
multi-processor servers. With all those threads you have you should be able
to make good use of such a platform.

Signature

Lew

Reply to this Message

FutureScalper - 14 Jan 2008 03:50 GMT

OK, thanks for the help.

I run a Quad Q6600 with 3+ mb usable RAM and Vista has an excellent
scheduler, so I don't need linux, etc. as you suggest.

You appear to be of the persuasion that one should not manipulate
thread priority. I don't think that's realistic in a near real-time
or "soft" realtime high performance application such as mine.

Anyway, thanks. I don't want to discuss it further.

Reply to this Message

Lew - 14 Jan 2008 04:23 GMT

> I run a Quad Q6600 with 3+ mb usable RAM and Vista has an excellent
> scheduler, so I don't need linux [sic], etc. as you suggest.
>
> You appear to be of the persuasion that one should not manipulate
> thread priority.

Well, that's a thorough misinterpretation of what I said. I wonder how you
arrived at that conclusion.

What I actually said was that I thought that manipulating the EDT priority
specifically would not be helpful. Didn't you catch the part where I
suggested altering the priority of the worker threads instead?

> I don't think that's realistic in a near real-time or "soft" realtime high performance application such as mine.

No disagreement here.

> Anyway, thanks. I don't want to discuss it further.

How about if you let us know the results of your research at least? Now that
you've gotten us involved it would be the nice thing to do.

Signature

Lew

Reply to this Message

Arne Vajhøj - 16 Jan 2008 03:29 GMT

> I run a Quad Q6600 with 3+ mb usable RAM

That was not much RAM ...

:-)

Arne