I have an app that uses the stock .NET 3.5 thread pool to spawn background workers which do some work, make an async WCF call (which does some LINQ to SQL), and then quit.
If this was an ASP.NET app I think I would be limited to 20 or 25 threads to get things like this done before I had to use a custom thread pool.
If I am doing the above in my own Win32 service (console app), does the same limit apply? The hardware is a dual processor system on Windows Server 2003.
> I have an app that uses the stock .NET 3.5 thread pool to spawn > background workers which do some work, make an async WCF call (which > does some LINQ to SQL), and then quit.
> If this was an ASP.NET app I think I would be limited to 20 or 25 > threads to get things like this done before I had to use a custom > thread pool.
> If I am doing the above in my own Win32 service (console app), does > the same limit apply? The hardware is a dual processor system on > Windows Server 2003.
I am not sure what the maximum limit is with windows services, but it is fairly easy to set up a thread pool using a ThreadPool object and set the Max threads to whatever you need to ensure your work is done properly. It would also be safer if you see this service doing more work over time, as you can spin it up with additional threads when it fails to scale.
> I have an app that uses the stock .NET 3.5 thread pool to spawn > background workers which do some work, make an async WCF call (which > does some LINQ to SQL), and then quit.
> If this was an ASP.NET app I think I would be limited to 20 or 25 > threads to get things like this done before I had to use a custom > thread pool.
> If I am doing the above in my own Win32 service (console app), does > the same limit apply? The hardware is a dual processor system on > Windows Server 2003.
> Thanks.
Will this help:
Private Sub Procedure2() Dim nl As String = Environment.NewLine
'Get a reference to the currently running thread... Dim currentThread As Thread = Thread.CurrentThread
'Set up some placeholders for the GetMaxThreads call Dim workerThreads As Integer Dim portThreads As Integer ThreadPool.GetMaxThreads(workerThreads, portThreads)
'Prepare a string with a bunch of data about the current thread. Dim sb As New System.Text.StringBuilder sb.Append(String.Format("CLR Thread ID: {0}{1}", currentThread.ManagedThreadId, nl)) sb.Append(String.Format("Windows Thread ID: {0}{1}", AppDomain.GetCurrentThreadId, nl)) sb.Append(String.Format("Thread priority: {0}{1}", currentThread.Priority, nl)) sb.Append(String.Format("Thread is in ThreadPool: {0}{1}", currentThread.IsThreadPoolThread, nl)) sb.Append(String.Format("ThreadState is: {0}{1}", currentThread.ThreadState.ToString, nl)) sb.Append(String.Format("Is this a background thread: {0}{1}", currentThread.IsBackground, nl)) sb.Append(String.Format("Max. worker threads in pool: {0}{1}", workerThreads, nl)) sb.Append(String.Format("Max. async. I/O threads in pool: {0}{1}", portThreads, nl))
SnapDive wrote: > I have an app that uses the stock .NET 3.5 thread pool to spawn > background workers which do some work, make an async WCF call (which > does some LINQ to SQL), and then quit.
> If this was an ASP.NET app I think I would be limited to 20 or 25 > threads to get things like this done before I had to use a custom > thread pool.
AFAIK, it doesn't matter what part of .NET you're using. ASP.NET, coding a service, writing a Forms application, etc. they all use the same ThreadPool defaults. And those defaults were 25 threads per CPU in early versions of .NET, updated to 250 threads per CPU in 2.0. I believe that remains the current default.
Note that the main reason for Microsoft changing the default was because too many people were coding thread pool deadlocks, and having a much larger pool allowed for a work-around to those bugs (with the much larger maximum, even buggy code was much less likely to get enough threads running for the deadlock to actually occur).
If you actually have hundreds of thread pool threads running, you may want to reconsider the design so as to avoid that many simultaneous operations (you should try to avoid having multiple threads all fighting each other for CPU time). An exception would be if your threads are all doing some kind of i/o that involves waiting for a significant time. In that case, there shouldn't be much CPU contention, because the threads are actually blocked on the i/o.
> If I am doing the above in my own Win32 service (console app), does > the same limit apply? The hardware is a dual processor system on > Windows Server 2003.
As I note above, I don't think the thread pool defaults vary according to context.
|
