By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,254 Members | 2,386 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,254 IT Pros & Developers. It's quick & easy.

Threading Question: Keeping the main UI responsive?

P: n/a

------------ (25K)

Main form with two listboxes, a textbox, a button, and a trackbar.

Clicking the button starts three new threads:
t1) Fill listbox1 with numbers in a loop. Each time a number is added
to the listbox, selected index is set to the new item and the listbox
is explicitly refreshed.
t2) Fill listbox2 with numbers in a loop. Each time ... (same as t1)
t3) Calculate Pi to 700 decimals and place the result in the textbox.

The trackbar is just there to test whether the UI responds to mouse

When running these three threads on a P4 with hyperthreading, there
are absolutely no problems. All threads seem to get an equal share of
time and the UI responds perfectly well.

Running the program on a Pentium M notebook (without hyperthreading,
of course), though, UI responsiveness is a hit or miss affair. Usually
a miss.

I suspect that the two listbox threads are taking too much time away
from the UI, as they are constantly updating the listboxes.

If I change the priority of the three threads to "BelowNormal" (as I
have done in the source I have linked to above), the UI responds just
fine on the Pentium M machine, but ...

1) If I run the worker threads using the BelowNormal priority, won't
just mean that other applications (e.g. a video encoder) will preempt
my application completely?

2) Instead of running the worker threads at BelowNormal priority,
would it be possible to run the main UI at AboveNormal priority and
the worker threads at normal priority?

This is just a test. The sample code could be prettier. I am a .Net
newbie, coming from 8 years of classic VB.

Eventually, the goal is to send a query to a SQL Server and have a
worker thread populate a listview or grid with a - potentially - large
result, yet allow the user to terminate this process at any time.

Is there a "best practice" for accomplishing this sort of thing?

The difference between running the code on a single-processor vs.
a (sort of) multi-processor one was a bit of a wake-up call, so I
guess I'll make sure I test such code on both types of machine in
the future :)


Joergen Bech

Nov 21 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.