Is ThreadPool per AppDomain?

[mabra]

Hi All !

Sorry, I could not find it :-(
If the threadpool would be per application domain, I could just create
another AppDomain to get another ThreadPool there. Alternately, I would
have to opt to some free ThreadPool implementations.

Any help would be great!

Thanks so far and
best regards,
Manfred

 

[Willy Denoyette [MVP]]

| Hi All !
|
| Sorry, I could not find it :-(
| If the threadpool would be per application domain, I could just create
| another AppDomain to get another ThreadPool there. Alternately, I would
| have to opt to some free ThreadPool implementations.
|
| Any help would be great!
|
| Thanks so far and
| best regards,
| Manfred

Nope, one per process.

Willy.

 

[Nicholas Paldino [.NET/C# MVP]]

Manfred,

The threadpool is pretty tuned to what your machine can handle. What is
it that you are trying to do? Why do you need more threads?

 

[mabra]

Hello Nicholas and All,

thanks first for the reply.

I need a lot of separate threads for longer running tasks [several
minutes], each connecting to other machines;Currently about 100. So far
I understand, I should use the threadpool only for shorter jobs. I could
easily create that amount of threads outside the pool and - due to the
nature of the jobs - they will not necessarily use too much cpu. That's
how I do it currently. But if the number of threads increases, that's
not a good solution and I do not need to have them all running
concurrently. From this point of view, the threadpool would be best. On
the other hand, I also use a lot of events and timers and I just
hesitate to schedule my about 100 additional thread to the theradpool
also. So the question about just another threadpool came to my mind.

Thanks so far and
best regards,
Manfred

 

[Nicholas Paldino [.NET/C# MVP]]

Manfred,

I think that you should first look at the tasks that you are performing.
If you can break those tasks down into smaller sub tasks, then you can load
them up into the thread pool, and that would be a better solution.

For example, you say you are connecting to other machines. How are you
connecting to them? Are you doing it over the network, performing database
or file operations? If so, perhaps you should use the async methods, and
then have a callback which will inform you when those operations are done.
Most of these will rely on IO completion ports, and not take up threadpool
threads.

Can you give some more information on how you are connecting to those
other machines?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello Nicholas and All,

thanks first for the reply.

I need a lot of separate threads for longer running tasks [several
minutes], each connecting to other machines;Currently about 100. So far I
understand, I should use the threadpool only for shorter jobs. I could
easily create that amount of threads outside the pool and - due to the
nature of the jobs - they will not necessarily use too much cpu. That's
how I do it currently. But if the number of threads increases, that's not
a good solution and I do not need to have them all running concurrently.
From this point of view, the threadpool would be best. On the other hand,
I also use a lot of events and timers and I just hesitate to schedule my
about 100 additional thread to the theradpool also. So the question about
just another threadpool came to my mind.

Thanks so far and
best regards,
Manfred

Manfred,

The threadpool is pretty tuned to what your machine can handle. What
is it that you are trying to do? Why do you need more threads?

 

[Willy Denoyette [MVP]]

| Hello Nicholas and All,
|
| thanks first for the reply.
|
| I need a lot of separate threads for longer running tasks [several
| minutes], each connecting to other machines;Currently about 100. So far
| I understand, I should use the threadpool only for shorter jobs. I could
| easily create that amount of threads outside the pool and - due to the
| nature of the jobs - they will not necessarily use too much cpu. That's
| how I do it currently. But if the number of threads increases, that's
| not a good solution and I do not need to have them all running
| concurrently. From this point of view, the threadpool would be best. On
| the other hand, I also use a lot of events and timers and I just
| hesitate to schedule my about 100 additional thread to the theradpool
| also. So the question about just another threadpool came to my mind.
|
| Thanks so far and
| best regards,
| Manfred
|
| Nicholas Paldino [.NET/C# MVP] wrote:
| > Manfred,
| >
| > The threadpool is pretty tuned to what your machine can handle.
What is
| > it that you are trying to do? Why do you need more threads?
| >
| >

When performing network IO in such scenario, you should use the asynchronous
network methods (BeginXXX/EndXXX), these use Completion Port threads.

Willy.

 

[mabra]

Hi !

It's complicated to describe. The application makes some management
tasks on a larger number of computers and I have WMI based connections,
access to remote files and the registry. This also has to be made in a
impersonated way [I am using .Net 1.1], because not all the environment
is on the same domain :-(

My handiest task is a class, which checks some files, the registry and
then connects via WMI [where the impersonation thing is not a problem]
to read a lot of classes. I just create a separate thread for this,
that's that easy ;-)

I know, this is sub-optimal ;-)
but better to handle with my experience. Otherwise, I had to break down
the class in more simpler sub-tasks, but for registry access - so far I
remember correctly - there is no chance to make async IO. Event the WMI
[explicit] connects have no async, as far as I understand this. I just
have to wait and then I start several queries [which itself most of them
could be async, which drive some higher programming effort].

So I came onto the idea to ask about the threadpool and/or use one of
the freee available versions as an additional pool.

I do not know, what all uses completion ports and how I can do async Io
in a impersonated way. I am also afraid of, that the free threadpool
implementations dont's allow this.

I'll keep in mind, what you recommend!

Thanks a lot,
Manfred

 

[mabra]

Hi Williy!

Thanks for your reply.
I shortly answered Nicolas question "above" ...

Best regards,
Manfred

 

[Willy Denoyette [MVP]]

| Hi Williy!
|
| Thanks for your reply.
| I shortly answered Nicolas question "above" ...
|

Ok, I see, you are using WMI which uses RPC's over SMB, that means that you
don't use any of the asynch IO mechanism in .NET, so forget about the
Completion ports.
For this kind of application I would base my design on "normal" managed
threads and not use threads from the pool. Depending on the number of
computers to manage, the number an type of RPC's you are executing (that is
the type of queries) and the available resources (CPU, memory and network)
in the management workstation, I would dedicate one thread per workstation
to start with, if the number of workstations/CPU is too high (say > 200) I
would opt to implement my own pool of threads and use a watchdog thread that
dynamically injects/retires threads into the pool depending on the CPU and
network load threshold.

Willy.