Question Differences in launching new threads

[sebadinoist]

Hello,

I have been using threads in windows services for a while, and have noticed (through usage and viewing other people's code) that there are different ways of launching new threads. Could anyone explain the difference in creating new threads in the following ways:

1)
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf myObj.mySub))

2)
myThread = New Thread(AddressOf myObj.mySub)
myThread.Start()

I am most interested in whether there is any performance advantage of either way. For the purposes of this, assume that I am running the service on a dedicated windows server 2008 with several threads running at the same time.

 

[JohnH]

I think the ThreadPool Class main help topic answers your questions, see: ThreadPool Class (System.Threading)
To sum it up, if you have just a few long running threads you can create and start a new thread, you can also use the pool for this if you don't have much other async work that need the pool. For many shorter async calls using the pool is best.

Some classes have async methods like "BeginWork" that some times uses pool and sometimes uses other ways for threading, using these methods can give better performance than running the synchronous counterpart in your own thread. Examples is async file and socket methods, I'm not sure if also ADO.Net async methods uses driver support for better IO performance than using managed threads.

Performance advantage of pool is that (when available) the thread is already created and running (idle threads). Management advantage for pool is you can queue many workers and you don't need to limit simultaneous worker threads yourself, since it is not efficient to run to much work at the same time. Limitation of pool is if you really need to run more threads at the same time than pool limit, or if you really need a thread to run in foreground. Also that the pool thread instance handling the current worker is concealed could be a limitation for some.

 

[sebadinoist]

Thanks for the info JohnH, it was really helpful.

The application I am working on has 4 main threads which constantly maintain connections to servers and send/recv data, so I am thinking that as it is a fixed number new threads will be best. I will launch these 4 threads at the start of the service and end them on service stop. The code inside each thread does indeed use async methods as you suggest.

I've done a couple of tests and it does appear that the Thread way means that the connections are kept up more efficiently as opposed to when I use the thread pool.

Thanks again!

 

[JohnH]

The code inside each thread does indeed use async methods as you suggest.

I didn't actually suggest that, but it can be a way to maintain persistent worker threads that manages/launches other small workers when you don't want to block the long running thread.

I've done a couple of tests and it does appear that the Thread way means that the connections are kept up more efficiently as opposed to when I use the thread pool.

Not exactly sure what you mean by that, a threadpool thread and a thread you create explicitly yourself is exactly the same thing, only pool has these management features that can affect startup performance and number of concurrent threads.