Thread about Threading...(Question) 1

[andegre]

I have a method that fires after a button click. Inside that method, it loads my list of users, once that is done, I want to determine whether each user is enabled or disabled, but I want that to be done in the background.

I am using the ThreadPool class for this, but when it get's to that part, it does it like it's single threaded...any help.

Here's a code snippet

if (lbList1.Items.Count > 0)
{
for (int x = 0; x < lbList1.Items.Count; x++)
{
tInfo = new ThreadInfoClass(lbList1.Items[x].ToString(), tbSourceDC.Text.ToString(), x);
ThreadPool.QueueUserWorkItem(new WaitCallback(LoadAllStatus1), tInfo);
Application.DoEvents();
}
}

 

[jmeckley]

I believe the problem is you are interacting with list items (GUI specific object) on a background thread.

I would pose a few questions though:
1. why are you using a thread pool for this? just do it on the current thread.
2. if you are having preformance problems 1st measure the preformance impact. Then optimize the bottleneck
a majority of the time this can be done by:
optimizing the query
caching
pushing work onto the background thread. in this case the querying and disable validation for the entire collection, not one item at a time.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[andegre]

This is ActiveDirectory lookups for determining the enabled/disabled. If I run in a single thread format, it will take around 5 minutes to load all of them (appox 3000 users in total get loaded).

Once the list of "just" the users is loaded, I would like to get the status of each of them in the background to allow the user to be able to click on a "user" in the list box so they can retrieve that user's information (while the enabled/disabled) is still processing in the backend.

Would it be better to use the backgroundworker instead? (FYI, this is my first EVER attempt at multi-threading...)

 

[jmeckley]

i see 2 problems.
1. modifying the GUI on a background thread
2. the amount of work you are putting on the background thread.

the problem is your are trying to performance tune the wrong section of code. threading is a highly complex concept. I would recommend researching the topic before you throw code at it.

1st. get a profiler (dotTrace is great) to determine where exactly the bottlenck is. you state that AD takes 5 minutes to query. if this i true then you need to adjust your AD query. limit the query to users only and return a subset of users.

I highly doubt you need 3000 users at once. find a way to either page the data, or have the end user ask for a subset of users. as they type in the name begin returning results which are similar. or have the user view 20 users at a time until they find the one they want.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[andegre]

Thanks Jason...

I've made some mods and its working better now, but still gives me a stackoverflowexception a little later but I'll look into that.

One last question, I am noticing that using the ThreadPool ties up alot of resources for the App and you can't do very much while it's running in the background, does the BackgroundWorker thread model reduce the amount of resources tied up by the backend processing? Will it be easier for the user to start selecting customers while it's loading that information behind the scenes?

Thanks again,

 

[jmeckley]

the benefits of threading is processing multiple requests in parallel. My understanding is this requires a multi-proc box. if your development machine, or the machines this app will be deployed on are single proc boxes then there is little to gain.

as i said before the problem is your AD query taking 5 minutes. focus on optimizing that query.

trying to fix the problem at the GUI with threading is the most complex, and least efficient way to increase responsiveness.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[andegre]

I understand...and just to clarify, it takes a total of about 5 minutes to load all 3000 users' status, not 5 minutes for each AD query.

 

[jmeckley]

it takes a total of about 5 minutes to load all 3000 users' status, not 5 minutes for each AD query.

either way, that's the problem.

another thought. User's do not change often. I would look at loading this information on a background thread when the application starts and caching the results, rather than loading them JIT.

Jason Meckley
Programmer
Specialty Bakers, Inc.