Channel 9 Forums - Tech Off - More Advanced ThreadPool

Tech Off - More Advanced ThreadPool

MetaGunny — Tue, 14 Aug 2007 17:53:53 GMT

I started using .NET 2.0 a couple of months ago and I knew I had this problem coming up soon and I was hoping the threadpool was enhanced. It doesn't look like it was.

Or, am I wrong and is there a more advanced threadpool or one already well written out there?

Basically, I don't want to throw a million items into the threadpool uncontrolled.

Here is going to be the flow:

1) Pick up all of the unprocessed records in the queue from the database. I'd probably limit it to 10000 or so at a time.

2) Limit it to processing 20 or so at a time.

3) After they are all completed, go back to the database and get the next 10000.

4) If a request comes in to stop, I want it to gracefully shut down and finish the 20 remaining items, rather than calling the join method or whatever it is to stop all threads immediately.

The main problem is when you use the .net threadpool and call adduserworkitem it will internally queue up all of the items and there is no way to see how many are completed, or to stop them gracefully.

The main thing is I don't want items processing while I perform the call to get the next 1000 records, that is why I want to make sure all are fully completed before going back to step 1.

I actually wrote a threadpool manager that did this but it had some problems where it would stop processing. I wanted to see if there is an elegant solution built-in, or anyone had any suggestions.

Thanks

Tech Off - More Advanced ThreadPool

pathfinder — Tue, 14 Aug 2007 19:07:43 GMT

I think you would be better off using regular Threads instead of threadpool. Just create 20 Threads and put them in a generic list to manage them. Then you can do whatever you want with the threads.

From experience, you can't rely on threadpool if you want pure performance. Thread pool will only do the work if there are resources. The more resources the more threads are running, the less system resources, the less threads are running.

I've seen thread pool go from 100 threads to 2 threads in a matter of minutes and never get back up in number again. With regular threads you are guaranteed that all 100 are running always.

Tech Off - More Advanced ThreadPool

ScanIAm — Tue, 14 Aug 2007 19:30:20 GMT

pathfinder wrote:

I think you would be better off using regular Threads instead of threadpool. Just create 20 Threads and put them in a generic list to manage them. Then you can do whatever you want with the threads.

From experience, you can't rely on threadpool if you want pure performance. Thread pool will only do the work if there are resources. The more resources the more threads are running, the less system resources, the less threads are running.

I've seen thread pool go from 100 threads to 2 threads in a matter of minutes and never get back up in number again. With regular threads you are guaranteed that all 100 are running always.

Ditto.

You are going to have to manually handle the part where you want any busy running threads to complete, anyway.

BTW, if your threading code was locking up, you're going to have to figure that part out. Usually, it's when multiple threads are accessing a non-thread-safe object without a lock on that object.

If you have questions about it, we might be able to help.

Tech Off - More Advanced ThreadPool

AndyC — Tue, 14 Aug 2007 20:10:20 GMT

pathfinder wrote:

I've seen thread pool go from 100 threads to 2 threads in a matter of minutes and never get back up in number again. With regular threads you are guaranteed that all 100 are running always.

100 running threads is a perf nightmare. Ideally you want the number of running threads to equal the number of logical processors and for those threads never to block. A certain amount of blocking is probably inevitable (unless you write hardcore fiber code) so in those cases you want to aim to have just enough threads to keep processor utilisation near 100% .

Tech Off - More Advanced ThreadPool

MetaGunny — Tue, 14 Aug 2007 21:34:39 GMT

Thanks guys. I actually don't remember having any perf problems. I just thought .net 2.0 might have added support for this.

The only problem I remember with my old code was the service stopped processing. However, I late found that was a bug in one of the .net classes and I rewrote my service base class using another method for other services and now they never stop.

You're right though I'll probably go the threading route rather than the threadpool. I've never had a problem with it dropping but it will be running on a server so that very well could happen.

However, when you say logic processes what do you mean? Let's say I have a quad core, is that 4 logical processors?

Tech Off - More Advanced ThreadPool

amotif — Wed, 15 Aug 2007 02:28:26 GMT

MetaGunny wrote:

However, when you say logic processes what do you mean? Let's say I have a quad core, is that 4 logical processors?

Yes. To over-simplify: if you have 4 CPU-intensive tasks that don't sleep or block on I/O, aren't being swapped out for other threads, and whose working set fits in the core's cache(s), you stand a better chance of keeping the 4 cores busy. Many real-life tasks don't quite fit within those boundaries.

Tech Off - More Advanced ThreadPool

Soviut — Wed, 15 Aug 2007 15:04:50 GMT

amotif wrote:

MetaGunny wrote:
However, when you say logic processes what do you mean? Let's say I have a quad core, is that 4 logical processors?

Yes. To over-simplify: if you have 4 CPU-intensive tasks that don't sleep or block on I/O, aren't being swapped out for other threads, and whose working set fits in the core's cache(s), you stand a better chance of keeping the 4 cores busy. Many real-life tasks don't quite fit within those boundaries.

This problem isn't really a performance issue though, its more to do with behaviour that the developer wants. He needs 10000 records processed and the performance of that processing really doesn't matter (of course it does, but not for this problem), its the ability to stop the operation but let all the threads finish.

Tech Off - More Advanced ThreadPool

AndyC — Wed, 15 Aug 2007 15:40:15 GMT

Soviut wrote:

This problem isn't really a performance issue though, its more to do with behaviour that the developer wants. He needs 10000 records processed and the performance of that processing really doesn't matter (of course it does, but not for this problem), its the ability to stop the operation but let all the threads finish.

True enough, but creating 100 threads isn't the way to solve it unless they're going to be spending a lot of time blocking. Otherwise you'll just be using all the CPU power performing context switches and never really getting any actual work done.

Tech Off - More Advanced ThreadPool

Soviut — Thu, 16 Aug 2007 15:13:31 GMT

AndyC wrote:

Soviut wrote:

This problem isn't really a performance issue though, its more to do with behaviour that the developer wants. He needs 10000 records processed and the performance of that processing really doesn't matter (of course it does, but not for this problem), its the ability to stop the operation but let all the threads finish.

True enough, but creating 100 threads isn't the way to solve it unless they're going to be spending a lot of time blocking. Otherwise you'll just be using all the CPU power performing context switches and never really getting any actual work done.

Naturally. But i think the "100 threads" was more of an example and not a suggestion.