ThreadPool vs. BackgroundWorkers

[PutterPlace]

I'm currently writing an application that is used to automate a certain task. Currently, it uses the threadpool (using up to 25 threads per the enduser's option). Each thread calls a function which will usually take about two minutes to finish, but it uses a While loop in order to repeat the process. This is my code to start the threads:

Private Sub ProcessAllItems()
    For i As Integer = 1 To Me.numThreads.Value Step 1
        Threading.ThreadPool.QueueUserWorkItem(New Threading.WaitCallback(AddressOf ProcessItem), i)
    Next i
End Sub

The function "ProcessItem()" is the function that contains the While loop. The control "Me.numThreads" is a NumericUpDown control whose max value is set to 25. My question is...is this a good method to follow? To my knowledge after .NET Framework SP1 there is a max of 250 threads/CPU. However I've read the the threadpool is normally used for processing short-lived tasks. Should I be using background workers instead? If so, how could I start up to 25 background workers during runtime depending on the value of "Me.numThreads"?

 

[jmcilhinney]

You shouldn't be doing either. You should be explicitly creating Thread objects and calling their Start method.

 

[PutterPlace]

Could you give me some example of how I could go about doing that?

 

[jmcilhinney]

Did you read the documentation for the Thread class or its Start method? Would you be surprised to learn that both topics include code examples? Whenever you know what type and/or member you need to use, the first thing you should do EVERY time is read the relevant MSDN documentation. That's what it's for. More often than not you'll get most, or all, of what you need. If you don't, then you can ask specific questions about the parts you still don't understand, but there's no need to ask others for examples when you already have such examples at your fingertips.

 

[PutterPlace]

I did read the dodumentation, but it was early and after reading over what I asked, I see that I should be more specific. Sorry about that.

When I'm creating the threads (not starting them) is there a way to use only the number of threads that are specified in the NumericUpDown control as I have done in my previous code. For example:

Dim Thread1 As Thread
Dim Thread2 As Thread
Dim Thread2 As Thread
etc...

That would be a long list of threads to declare, and even longer just to start them (my NumericUpDown control has a max value of 25). But to explicitly declare each one and start each one seems to be somewhat lengthy. If that's the only way to do it, then I'm all for it. However, if there is a shorter method or some loop that I can write that will ONLY declare and/or start the number of threads specified by "Me.numThreads.Value", that would be even better.

 

[JohnH]

There is no reason you can't use a loop to create Thread instances.

 

[PutterPlace]

I've searched, but couldn't find anything that could help in dynamically creating the variables as such:

Dim Thread1 As New Thread(AddressOf SomeFunction)
Dim Thread2 As New Thread(AddressOf SomeFunction)
'etc....

Thread1.IsBackground = True
Thread2.IsBackground = True
'etc....

Thread1.Start()
Thread2.Start()
'etc...

How would I construct a loop to create all of the thread instances without having so many lines of code?

 

[JohnH]

for <clause>
 dim x as new thread
 x.start
next

 

[PutterPlace]

I didn't know that you could have multiple instances of the same thread. So would the following be correct?

Private Sub ProcessAllItems()
    For i As Integer = 1 To Me.numThreads.Value Step 1
        Dim ThreadX as New Thread(AddressOf ProcessItem)
        ThreadX.Name = "Thread" & i
        ThreadX.Start()
    Next i
End Sub

Private Sub ProcessItem()
    'Code Here
End Sub

 

[jmcilhinney]

That is correct, but it's not multiple instances of the same thread. It's multiple threads all executing the same method. It's exactly the same as what you were doing originally except that you're creating the threads explicitly instead of letting the system manage them.

 

[PutterPlace]

Ahh. Alright. That will work perfectly. Thank you so much for your help. That's exactly why I love this forum.

 

[cjard]

You shouldn't be doing either. You should be explicitly creating Thread objects and calling their Start method.

Care to elaborate as to why?

 

[JohnH]

Care to elaborate as to why?

Both ThreadPool.QueueUserWorkItem and BackgroundWorker uses threadpool, which limits to 25 concurrent threads. OP needs 25 threads to run for an indefinite time (2 minutes work repeated with some While), so why tie up the whole pool when you don't need to? For such work there is no benefit in startup speed or queueing, and making UI callbacks or adding cancel/busy flags is easy without the BGW should one need to (while it was not a request here). It also sounds like OP want to experiment with more than 25 simultaneous threads, I wouldn't use SetMaxThreads on pool to control this.

 

[PutterPlace]

That was exactly what I wanted to do. As of right now, I have my users limited to using 25 threads, but this will definitely give me the option to increase the number of threads if needed. Which is exactly what I'm going to be doing.

Thanks again.

 

[Mikla]

Could he also do something like:

Dim oThread(1) As System.Threading.Thread
ReDim oThread(Me.numThreads.Value - 1)

For i As Integer = 0 To Me.numThreads.Value - 1 Step 1
    oThread(i) = New System.Threading.Thread(AddressOf ProcessItem)
    oThread(i).Name = "Thread" & i
    oThread(i).Start
Next

I was thinking it might make managing the threads a little easier. For instance, you could check the threads with something like:

For i As Integer = 0 To Me.numThreads.Value - 1 Step 1
    If oThread(i).IsAlive Then
        'Do something
    Else
        'The thread is available again
    End If
Next