Question about ThreadPool

[Peter Kirk]

Hi,

I see in the ThreadPool documentation that the pool has a default limit of
25 threads.

Is it correctly understood that this limit is for my entire application? So
if I have several worker-threads each using "ThreadPool.QueueUserWorkItem"
then the limit is spread over all my worker-threads - so if
"worker-thread-1" currently has 20 calls in progress then there are only 5
thread-pool threads available for "worker-thread-2" ?

Thanks,
Peter

[Richard Blewett [DevelopMentor]]

So you have 2 worker threads each making calls to ThreadPool.QueueUserWorkItem.

The thread pool limit is 25 threads *per processor* and is a per process limit. This value cannot be changed from managed code (this changes in v2.0) although there is an unmanaged code API to do it. Mike Woodring has written a sample that wraps the necessary interop calls in a .NET component [1].

The one question really is what are these thread pool threads doing? The threadpool is really for relatively short lived work - if you are exhausting the thread pool you must be generating alot of threadpool work or the each work item must be taking a while to execute.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

[1] http://www.bearcanyon.com/dotnet/#tpcontrol

Hi,

I see in the ThreadPool documentation that the pool has a default limit of
25 threads.

Is it correctly understood that this limit is for my entire application? So
if I have several worker-threads each using "ThreadPool.QueueUserWorkItem"
then the limit is spread over all my worker-threads - so if
"worker-thread-1" currently has 20 calls in progress then there are only 5
thread-pool threads available for "worker-thread-2" ?

Thanks,
Peter

[BravesCharm]

I think it's 25 threads per AppDomain? Anyhow, ThreadPool should only
be used when performing operations that will not run a very long time.
It ti will run a long time you should create your own thread like this:
Thread WorkerThread = new Thread(new ThreadStart(MyWorkerThreadFun));
WorkerThread.Name = "My Worker Thread"; // looks nice in Output
window
WorkerThread.Start();

and the function should look like this

private void MyWorkerThreadFun()
{
}

[Peter Kirk]

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> skrev i en
meddelelse news:uD****************@tk2msftngp13.phx.gbl...

So you have 2 worker threads each making calls to
ThreadPool.QueueUserWorkItem.

The thread pool limit is 25 threads *per processor* and is a per process
limit. This value cannot be changed from managed code (this changes in
v2.0) although there is an unmanaged code API to do it. Mike Woodring has
written a sample that wraps the necessary interop calls in a .NET
component [1].

The one question really is what are these thread pool threads doing? The
threadpool is really for relatively short lived work - if you are
exhausting the thread pool you must be generating alot of threadpool work
or the each work item must be taking a while to execute.

I have a lot of work to do. I have to execute about 10000 queries against a
search engine, each of which will take a long time (15 seconds to 5 minutes)
to complete.

I wanted to put these into some threads to try to help throughput. Obviously
10000 threads is too much - but what is good? I though 25 threads sounded
too little. I must admit that I haven't actually tested anything yet because
there is no real data yet to work on - I know one shouldn't "optimise" too
early, and maybe the search engine won't handle a large number of
simultaneous requests anyway... so maybe I need to wait, just wanted to keep
ahead.

Any advice appreciated.
Thanks,

Peter

[Reginald Blue]

Peter Kirk wrote:

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> skrev
i en meddelelse news:uD****************@tk2msftngp13.phx.gbl...

The one question really is what are these thread pool threads doing?
The threadpool is really for relatively short lived work - if you are
exhausting the thread pool you must be generating alot of threadpool
work or the each work item must be taking a while to execute.

I have a lot of work to do. I have to execute about 10000 queries
against a search engine, each of which will take a long time (15
seconds to 5 minutes) to complete.

I wanted to put these into some threads to try to help throughput.
Obviously 10000 threads is too much - but what is good? I though 25
threads sounded too little. I must admit that I haven't actually
tested anything yet because there is no real data yet to work on - I
know one shouldn't "optimise" too early, and maybe the search engine
won't handle a large number of simultaneous requests anyway... so
maybe I need to wait, just wanted to keep ahead.

The built in Thread Pool is not the solution to your problem. It's designed
for short, high CPU, low I/O operations. Your requirements are long, low
CPU, high I/O operations.

I see 2 alternatives:

1. Build your own thread pool which will balance things to your needs.
This can be quite challenging.

2. Use Asynchronous I/O. This is likely the optimal way to go. You could
use the build in Thread Pool to handle the return information from the Async
I/O... that'd probably work fairly well.

By the way, it's entirely possible to overwhelm the target system with a
huge number of outstanding requests. You'll want to be careful about that,
I would expect.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Jon Skeet [C# MVP]]

Peter Kirk <[e-mail]> wrote:

I wanted to put these into some threads to try to help throughput. Obviously
10000 threads is too much - but what is good? I though 25 threads sounded
too little. I must admit that I haven't actually tested anything yet because
there is no real data yet to work on - I know one shouldn't "optimise" too
early, and maybe the search engine won't handle a large number of
simultaneous requests anyway... so maybe I need to wait, just wanted to keep
ahead.

If they're all going to the same database, the chances are that having
more than a few threads won't actually increase the throughput at all.
You only gain performance if you're spreading your bottleneck out over
different resources.

However, I'd suggest not using the system threadpool, but a custom one.
That way you end up with a far smaller chance of deadlocking, because
you know the system won't be trying to use the same threadpool for
async calls etc.

See http://www.pobox.com/~skeet/csharp/miscutil

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too