UI has highest thread priority, yet it is still slow when background threads work

  • Thread starter Thread starter rpatel4
  • Start date Start date
R

rpatel4

I've got about 5 thread in my application.
One of the threads downloads data from the internet
I gave the UI the highest priority
System.Threading.Thread.CurrentThread.Priority =
System.Threading.ThreadPriority.Normal;

I gave all other threads a lower priority
_threadObject.Priority = System.Threading.ThreadPriority.BelowNormal;

Yet when the background threads are downloading data, the UI is
noticeably slower.
Am I doing something wrong here, is there any other way to get the UI
to have priority over the background?

(While I was writing this I came up with a possible issue -- that a
background thread has acquired a mutex and the UI is blocking until the
background releases that mutex -- I'll check this code for this but if
its not any other solutions?)
 
I wouldn't think it would cause a huge slowdown, but when you're doing
network activity, there are a lot of higher-than-you priority threads
running (the interrupt handler for the network chip, for example). What
sort of method are you using to decide that the UI is slow? What is it
doing? And, just to be sure, you *are* setting that priority in the context
of your background thread, right? Not accidentally changing the priority of
the UI thread?

Paul T.
 
HI Paul,

Thanks for the info.

As far as how I'm determining that the UI is slow...I've got a panel
that contains a list of items (its an owner drawn list), and I've got a
combo box that when I click(or key) right or left, it refreshes the
panel with different items. Anyways, the movement up/down the list, as
well as left/right in the combo box is considerably slower when the
background threads are going at it, then it is when the background
threads are idle.

The thread priorities appear to be set correctly (I'm reading the
priority into an int and setting a breakpoint and the priority's int
value is correct).

It code be that background (the network's interrupt handler) has
priority over my app threads and thus are slowing down UI. As a test,
I'll throw in a sleep(1) after every network call and if that solves it
(its not an ideal solution) I'll move on for now.

Thanks,
R Patel
 
And the data being displayed has no relationship to anything that any of the
threads are doing? Remember that the scheduler always will give *all* of
the processor time to the highest-priority thread which is ready to run. If
your main program thread, for example, is always ready to run (as an
example, let's say it's a while loop that never blocks on any call that it
makes), the other threads will get *zero* time, starving them completely.
It must be some interaction between the threads, then, which is causing the
effect that you're seeing.

Paul T.
 
"the data being displayed has no relationship to anything that any of
the threads are doing"
This is not completely true.
You're info does clear things up. If its not a priority issue, the
slowness must be due to the UI blocking on a locked object, and I'll
step thru the UI code looking for any blocking calls (I don't know for
sure if they exist since I didn't write most of this app).
Thanks...
 
The UI shouldn't be calling anything that will block for *any* significant
period of time, other than GetMessage(), in the main message loop.

Paul T.

"the data being displayed has no relationship to anything that any of
the threads are doing"
This is not completely true.
You're info does clear things up. If its not a priority issue, the
slowness must be due to the UI blocking on a locked object, and I'll
step thru the UI code looking for any blocking calls (I don't know for
sure if they exist since I didn't write most of this app).
Thanks...

And the data being displayed has no relationship to anything that any of
the
threads are doing? Remember that the scheduler always will give *all* of
the processor time to the highest-priority thread which is ready to run.
If
your main program thread, for example, is always ready to run (as an
example, let's say it's a while loop that never blocks on any call that
it
makes), the other threads will get *zero* time, starving them completely.
It must be some interaction between the threads, then, which is causing
the
effect that you're seeing.

Paul T.

HI Paul,

Thanks for the info.

As far as how I'm determining that the UI is slow...I've got a panel
that contains a list of items (its an owner drawn list), and I've got a
combo box that when I click(or key) right or left, it refreshes the
panel with different items. Anyways, the movement up/down the list, as
well as left/right in the combo box is considerably slower when the
background threads are going at it, then it is when the background
threads are idle.

The thread priorities appear to be set correctly (I'm reading the
priority into an int and setting a breakpoint and the priority's int
value is correct).

It code be that background (the network's interrupt handler) has
priority over my app threads and thus are slowing down UI. As a test,
I'll throw in a sleep(1) after every network call and if that solves it
(its not an ideal solution) I'll move on for now.

Thanks,
R Patel

Paul G. Tobey [eMVP] wrote:
I wouldn't think it would cause a huge slowdown, but when you're doing
network activity, there are a lot of higher-than-you priority threads
running (the interrupt handler for the network chip, for example).
What
sort of method are you using to decide that the UI is slow? What is
it
doing? And, just to be sure, you *are* setting that priority in the
context
of your background thread, right? Not accidentally changing the
priority
of
the UI thread?

Paul T.

I've got about 5 thread in my application.
One of the threads downloads data from the internet
I gave the UI the highest priority
System.Threading.Thread.CurrentThread.Priority =
System.Threading.ThreadPriority.Normal;

I gave all other threads a lower priority
_threadObject.Priority =
System.Threading.ThreadPriority.BelowNormal;

Yet when the background threads are downloading data, the UI is
noticeably slower.
Am I doing something wrong here, is there any other way to get the
UI
to have priority over the background?

(While I was writing this I came up with a possible issue -- that a
background thread has acquired a mutex and the UI is blocking until
the
background releases that mutex -- I'll check this code for this but
if
its not any other solutions?)
Click to expand...
Click to expand...
Click to expand...
 
Back
Top