Setting GUI thread priority

Discussion in 'Java' started by FutureScalper, Jan 12, 2008.

  1. 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?
     
    FutureScalper, Jan 12, 2008
    #1
    1. Advertising

  2. FutureScalper

    Lew Guest

    FutureScalper wrote:
    > 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?

    --
    Lew
     
    Lew, Jan 12, 2008
    #2
    1. Advertising

  3. 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"/
    >



    On Jan 11, 11:22 pm, Lew <> wrote:
    > FutureScalper wrote:
    > > 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?
    >
    > --
    > Lew
     
    FutureScalper, Jan 14, 2008
    #3
  4. FutureScalper

    Lew Guest

    FutureScalper wrote:
    > 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
    > 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.


    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,
    > 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 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.

    --
    Lew
     
    Lew, Jan 14, 2008
    #4
  5. 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.
     
    FutureScalper, Jan 14, 2008
    #5
  6. FutureScalper

    Lew Guest

    FutureScalper wrote:
    > 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.

    --
    Lew
     
    Lew, Jan 14, 2008
    #6
  7. FutureScalper

    Arne Vajhøj Guest

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


    That was not much RAM ...

    :)

    Arne
     
    Arne Vajhøj, Jan 16, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alistair Atkinson

    Setting the priority a WebStart app

    Alistair Atkinson, Sep 20, 2003, in forum: Java
    Replies:
    5
    Views:
    394
    Alistair Atkinson
    Sep 24, 2003
  2. Replies:
    2
    Views:
    6,988
    tom fredriksen
    Mar 13, 2006
  3. Replies:
    0
    Views:
    372
  4. Replies:
    0
    Views:
    326
  5. Marcel Müller
    Replies:
    3
    Views:
    581
    Marcel Müller
    Apr 27, 2009
Loading...

Share This Page