Threads vs Thread Pool

It applies only to thread pool and not to threads. The threadpool size
also can be changed from 25 to a greater number.

"Naveen" <na*********************@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

It applies only to thread pool and not to threads. The threadpool size
also can be changed from 25 to a greater number.

The default cap in the thread pool is 25 thread *per processor* so on a 2
processor machine it defaults to 50. However, in v2.0 you can change the
number of threads the thread pool caps to via the ThreadPool.SetMaxThreads()
call.

Regards

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

25 is just a default and you can configure it. As for your own threads, you
can keep creating as many as you want ... until you crash the machine, that
is. :-)

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"vzaffiro" <Vi*************@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...

Does the magic number of 25 only apply to the thread pool? Does it also
apply to manually creating threads?

<splittinghairs>
you will run out of stack space long before you crash the machine on most
machines

A process in windows is generally only allowed 2 gb of memory ... by default
every thread that you start up uses 1 mb of stack space. As such the maximum
would be 2000 :) You can however set the stack size of threads (in 1.x via a
direct call to CreateThread, in 2.0 an overloaded constructor)
</splittinghairs>

:)

Cheers,

Greg
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in
message news:eo**************@TK2MSFTNGP02.phx.gbl...

25 is just a default and you can configure it. As for your own threads,
you can keep creating as many as you want ... until you crash the machine,
that is. :-)

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"vzaffiro" <Vi*************@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...

Does the magic number of 25 only apply to the thread pool? Does it also
apply to manually creating threads?

> you will run out of stack space long before you crash the machine on most

machines Nope. As I demonstrated earlier this week, the machine crashes long before
the out of memory exception is thrown.

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Greg Young" <Dr*************@hotmail.com> wrote in message
news:uO**************@TK2MSFTNGP03.phx.gbl... <splittinghairs>
you will run out of stack space long before you crash the machine on most
machines

A process in windows is generally only allowed 2 gb of memory ... by
default every thread that you start up uses 1 mb of stack space. As such
the maximum would be 2000 :) You can however set the stack size of threads
(in 1.x via a direct call to CreateThread, in 2.0 an overloaded
constructor)
</splittinghairs>

:)

Cheers,

Greg
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in
message news:eo**************@TK2MSFTNGP02.phx.gbl...

25 is just a default and you can configure it. As for your own threads,
you can keep creating as many as you want ... until you crash the
machine, that is. :-)

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"vzaffiro" <Vi*************@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...

Does the magic number of 25 only apply to the thread pool? Does it also
apply to manually creating threads?

Hello Cowboy (Gregory A. Beamer),

Take into accout that they say the 25 is the maximum number if thead that
can give u visible performance.
Increasing that number of thread don't give u any advantage, notwithstanding
the system size and complexity.
C> 25 is just a default and you can configure it. As for your own
C> threads, you can keep creating as many as you want ... until you
C> crash the machine, that is. :-)

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

"Michael Nemtsev" <ne*****@msn.com> wrote in message
news:9c**************************@msnews.microsoft .com...

Hello Cowboy (Gregory A. Beamer),

Take into accout that they say the 25 is the maximum number if thead that
can give u visible performance.
Increasing that number of thread don't give u any advantage,
notwithstanding the system size and complexity.

I think thats possibly a bit of a generalisation. For example, ASP.NET
increases this value to 50 by default. Surely it depends on what the
appliction is doing, how much contention there is for shared resources and
that kind of thing.

For example, if I had a remoting server (remoting dispatches calls on thread
pool threads) and those remoting calls were accessing discrete parts of a
database or separate files on the file system why would limiting the app to
25 concurrent calls be a good thing and what would prevent those calls from
being multiplexed higher by increasing the maxiumum umber of threads in the
pool?

Regards

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

Hello Richard Blewett [DevelopMentor]" richard at nospam dotnetconsult dot
co dot uk,

Yep, it's only generalization. AFAIK they choose number 25 as a golden mean.

But as you say, everything depends on our own project. We need to measure
the cost of thread's context switch and decide whether is there any advantage
of increasing the number of our thread.

Take into accout that they say the 25 is the maximum number if thead
that
can give u visible performance.
Increasing that number of thread don't give u any advantage,
notwithstanding the system size and complexity.

R> I think thats possibly a bit of a generalisation. For example,
R> ASP.NET increases this value to 50 by default. Surely it depends on
R> what the appliction is doing, how much contention there is for shared
R> resources and that kind of thing.
R>
R> For example, if I had a remoting server (remoting dispatches calls on
R> thread pool threads) and those remoting calls were accessing discrete
R> parts of a database or separate files on the file system why would
R> limiting the app to 25 concurrent calls be a good thing and what
R> would prevent those calls from being multiplexed higher by increasing
R> the maxiumum umber of threads in the pool?

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

"Richard Blewett [DevelopMentor]" <richard at nospam dotnetconsult dot co
dot uk> wrote in message news:uU**************@TK2MSFTNGP02.phx.gbl...
| "Michael Nemtsev" <ne*****@msn.com> wrote in message
| news:9c**************************@msnews.microsoft .com...
| > Hello Cowboy (Gregory A. Beamer),
| >
| > Take into accout that they say the 25 is the maximum number if thead
that
| > can give u visible performance.
| > Increasing that number of thread don't give u any advantage,
| > notwithstanding the system size and complexity.
|
| I think thats possibly a bit of a generalisation. For example, ASP.NET
| increases this value to 50 by default. Surely it depends on what the
| appliction is doing, how much contention there is for shared resources and
| that kind of thing.
|
| For example, if I had a remoting server (remoting dispatches calls on
thread
| pool threads) and those remoting calls were accessing discrete parts of a
| database or separate files on the file system why would limiting the app
to
| 25 concurrent calls be a good thing and what would prevent those calls
from
| being multiplexed higher by increasing the maxiumum umber of threads in
the
| pool?
|
| Regards
|
| Richard Blewett - DevelopMentor
| http://www.dotnetconsult.co.uk/weblog
| http://www.dotnetconsult.co.uk
|
|

Richard,
In the remoting scenario (and ASP.NET) , the requests are handled by the
Completion port threads not on the worker threads from the thread pool.
You can check this by calling ThreadPool.GetAvailableThreads.
In a remote server application of mine where I have 50 clients
simultaneously calling a remoting server, I get the following values for the
thread pool threads:

Max worker threads = 50, available = 50
Max I/O threads = 1000, available = 995

Note that this was taken on a dual CPU box (hence the 50 workers), see there
are no worker threads taken, the number of IOCP threads varies between 2 and
6, but this highly depends on the task, but I never saw more than 10-12 IOCP
threads running on a dual CPU box.

Willy.

> Richard,

In the remoting scenario (and ASP.NET) , the requests are handled by the
Completion port threads not on the worker threads from the thread pool.
You can check this by calling ThreadPool.GetAvailableThreads.
In a remote server application of mine where I have 50 clients
simultaneously calling a remoting server, I get the following values for
the
thread pool threads:

Max worker threads = 50, available = 50
Max I/O threads = 1000, available = 995

Note that this was taken on a dual CPU box (hence the 50 workers), see
there
are no worker threads taken, the number of IOCP threads varies between 2
and
6, but this highly depends on the task, but I never saw more than 10-12
IOCP
threads running on a dual CPU box.

Willy.

Ahh interesting - I knew it was handled by the threadpool but I always
assumed it was worker threads (although i guess its up to the channel) - thx
for the clarification.

Regards

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

"Richard Blewett [DevelopMentor]" <richard at nospam dotnetconsult dot co
dot uk> wrote in message news:el**************@TK2MSFTNGP03.phx.gbl...
|> Richard,
| > In the remoting scenario (and ASP.NET) , the requests are handled by the
| > Completion port threads not on the worker threads from the thread pool.
| > You can check this by calling ThreadPool.GetAvailableThreads.
| > In a remote server application of mine where I have 50 clients
| > simultaneously calling a remoting server, I get the following values for
| > the
| > thread pool threads:
| >
| > Max worker threads = 50, available = 50
| > Max I/O threads = 1000, available = 995
| >
| > Note that this was taken on a dual CPU box (hence the 50 workers), see
| > there
| > are no worker threads taken, the number of IOCP threads varies between 2
| > and
| > 6, but this highly depends on the task, but I never saw more than 10-12
| > IOCP
| > threads running on a dual CPU box.
| >
| > Willy.
| >
| >
|
| Ahh interesting - I knew it was handled by the threadpool but I always
| assumed it was worker threads (although i guess its up to the channel) -
thx
| for the clarification.
|

Well, I'm using tcp (across the network) and ipc (cross-process)channels and
both are using IOCP threads to handle the requests, this is quite normal as
both use the asynchronous I-O support mapped on CP's in .NET.
Note that in a tcp scenario, the number of CP threads used highly depend on
the number of CPU's and their speed, the network speed and topology and the
actual network load and the call payload.
Willy.