Thread Count in Task Manager

  • Thread starter Thread starter Doug Thews
  • Start date Start date
D

Doug Thews

I saw something interesting when testing my multi-threaded code to make sure
that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?

Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
..NET was actually spinning up 2 other threads during this "extra" time, and
then killed the threads after it did something in the background. Probably
some kind of exception (on top of my exception handling), or cleanup.
Anyway, the thread count bounces up only on the very first Thread.Abort. If
I re-create a new thread and abort it, this scenario (and the delay) doesn't
occur.
 
I think you're seeing are

The GC Thread
The Finalization Thread
The ThreadPool Manager Thread

I'm not sure whats happening with the Thread.Abort scenario at the moment but maybe digging in the ROTOR source might give you some clue

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

I saw something interesting when testing my multi-threaded code to make sure
that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?

Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time, and
then killed the threads after it did something in the background. Probably
some kind of exception (on top of my exception handling), or cleanup.
Anyway, the thread count bounces up only on the very first Thread.Abort. If
I re-create a new thread and abort it, this scenario (and the delay) doesn't
occur.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/





---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 08/10/2004



[microsoft.public.dotnet.languages.csharp]
 
Doug Thews said:
I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?
Click to expand...

As Richard stated, the threads could be for GC, threadpool, and the
finalization queue. The 4th could be the main thread of your application.
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time,
and then killed the threads after it did something in the background.
Probably some kind of exception (on top of my exception handling), or
cleanup. Anyway, the thread count bounces up only on the very first
Thread.Abort. If I re-create a new thread and abort it, this scenario
(and the delay) doesn't occur.
Click to expand...

Were you running under a debugger when you threw the abort? If so, then it
could be the debugger spinning up some threads to synchronize access to the
debugged application. Even when not running under a debugger it could be the
win32 subsystem creating a thread to notify any attached debuggers of a 1st
chance exception.
 
Cool, thanks for the info. So, ANY WinForms .NET application is going to
have 4 threads to start? I guess I'd always thought of the .NET runtime as
a single instance, so the GC, etc would exist in their own little worlds,
being called on the .NET AppDomains when necessary.
 
Hmm..I actually think that ANY .NET app (not just Winforms) would have 4
threads on startup - but I have to check this though. One way to check this
is to load up WinDbg and use the threads command to see what is running in
what
 
This is the minimum number of threads created when running the workstation
version of the CLR.
Two of them are managed threads (EE threads) the other two are used for
debugging services.

Thread 0 : Applications main thread (managed)
Thread 1 : Debugger Runtime Controller thread (unmanaged)
Thread 2 : Finalizer thread (managed)
Thread 3 : Debugger thread (unmanaged)

Willy.
 
If the app is compiled for "release" mode (i.e. no debug), then will the 2
debugger threads not get instantiated?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/



Willy Denoyette said:
This is the minimum number of threads created when running the workstation
version of the CLR.
Two of them are managed threads (EE threads) the other two are used for
debugging services.

Thread 0 : Applications main thread (managed)
Thread 1 : Debugger Runtime Controller thread (unmanaged)
Thread 2 : Finalizer thread (managed)
Thread 3 : Debugger thread (unmanaged)

Willy.
Click to expand...
 
Both are unrelated, you can also debug "non debug" assemblies, or
dynamically loaded assemblies don't you?
The two threads are always created before Execution Engine startup, this is
done long before the assembly loader kicks in.
Note that these threads are used to debug the CLR itself and that the
DebuggerRCThread also serves many other purposes like profiler and perfmon
IPC(delivering CLR perfcounters).

Willy.



Doug Thews said:
If the app is compiled for "release" mode (i.e. no debug), then will the 2
debugger threads not get instantiated?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
Click to expand...
 
Back
Top