Using ThreadPool

[Lucas Tam]

Is there a document online which details the advantages of using a
Threadpool?

My application uses a user configuration amount of threads which does the
following:


Main Thread Gives Work to Sub Thread
Sub Thread Import/Export Record
Sub Thread Import/Export Record
etc...

Once the thread is down its job, the thread exists. The Main Thread
(application) continues running until a timer hits, and the process is
repeated.

Does it make sense to use a threadpool? My threads exit after their work is
complete. Typically I have 1 or 2 sub threads running and about 50+ work
items.

 

[Cor Ligthert]

Lucas,

Did you see this answer Jay has sand last month?

I thought your question is at the bottom, he write it real nice in my
opinion.

http://groups.google.com/groups?selm=#[email protected]

Cor

"Lucas Tam"

 

[Jay B. Harlow [MVP - Outlook]]

Lucas,
In addition to Cor's & other comments:

Jon Skeet has a number of articles on threads & thread pools. They are in
C#, however they should be easily converted to VB.NET.

http://www.yoda.arachsys.com/csharp/threads/

http://www.yoda.arachsys.com/csharp/threadstart.html

There is an alternative thread pool here, allowing you to limit the number
of threads to two.
http://www.yoda.arachsys.com/csharp/miscutil/

Once the thread is down its job, the thread exists. The Main Thread
(application) continues running until a timer hits, and the process is
repeated.

Creating threads can be expensive. If you only have 2 "threads" running at a
time, I would consider only having 2 threads, in addition to the main
thread.

The main thread would add work items to a System.Collections.Queue, the 2
worker threads would read work items from the queue in a loop. When a worker
thread is done with one work item, it would loop back & read another item.

Hope this helps
Jay

 

[Lucas Tam]

The main thread would add work items to a System.Collections.Queue,
the 2 worker threads would read work items from the queue in a loop.
When a worker thread is done with one work item, it would loop back &
read another item.

Hmmm that's a good idea too. Never thought of that : )

 

[Jay B. Harlow [MVP - Outlook]]

Lucas,
Here is a prior post I made regarding this subject.

Normally I have a single worker thread, Looking at my code below, I believe
it will work with multiple worker threads.


For Queue I normally use a System.Threading.AutoResetEvent along with the
Queue. Depending on the parameters you pass to the AutoResetEvent.WaitOne
method, the background thread will sleep indefinitely waiting for the event
to be signaled.

The background thread has two loops. The outer loop does an
AutoResetEvent.WaitOne waiting for the event to be signaled. When the event
is signaled the background thread has an inner loop processing each item in
the queue.

When other threads put work items into the queue they Set the above
AutoResetEvent, letting the background thread know there is at least one
item in the queue.

Normally I put the Thread, the AutoResetEvent, the Queue and the padlock for
the Queue into a single class that represents the "Worker". Encapsulating
the above into clean type safe methods.

Something like:

' untested, typed from memory.
Public Class ThreadRequestQueue

Private Readonly m_padlock As New Object
Private Readonly m_queue As New Queue
Private Readonly m_event As New AutoResetEvent(False)

Public Sub AddRequest(ByVal request As Object)
SyncLock m_padlock
m_queue.Enqueue(Object)
End SyncLock
m_event.Set()
End Sub

Public Function GetRequest() As Object
' Check to see if there are already items available
SyncLock m_padlock
If m_queue.Count() > 0 Then
Return m_queue.DeQueue()
End If
End SyncLock

' Cannot block main thread
' while waiting for the main thread to add requests
' hence no SyncLock here
m_event.WaitOne()

' There must be an item
SyncLock m_padlock
Return m_queue.Dequeue()
End SyncLock
End Function

End Class

Hope this helps
Jay