Do-Nothing WinForm App Using 4 Threads?

[gsimmons]

I've been researching multi-threaded WinForms apps and thread
synchronization stuff for a couple days since I'm working on
refactoring a multi-threaded GUI app at work and want to be sure it's
rock solid/thread-safe. I've seen all the posts about using BeginInvoke
to have worker threads interact with the UI. My question is this:

I created a plain old Windows Form application (VS.NET 2005) with a
blank form, built it (release build), ran it from Windows Explorer and
Task Manager claims the application is using four threads. What are
they? Obviously one is the main app/UI. What are the others?

I then added a Windows Timer control to the form and updated a label
every second. Still four threads. I expected a timer to be on its own
thread even though it posts "tick" events to the UI message
loop/thread.

I removed the Windows Timer and replaced it with a System Timer which
runs "tick" events on a different thread, yet the thread count still
stays at four. Huh?

Is there a built-in thread pool with a few workers hanging around to do
timers and stuff? What exactly is going on here?
Are those extra threads part of the CLR doing its magic to run the EXE?
Other?

My next question will be how many threads remoting (inter-process on
the same PC) adds to the mix. The UI app I'm refactoring makes use of
several remote objects (running methods and receiving events with
data). I'm guessing there is a thread for each proxy/socket to handle
marshalling stuff. And the event handling from remote objects
supposedly grabs a thread from the thread pool. Inquiring minds what to
really KNOW what's going on under the hood.

Pointers to good articles and/or books welcome. Spend the last weekend
Googling and reading...

Thanks!

 

[Larry Lard]

I've been researching multi-threaded WinForms apps and thread
synchronization stuff for a couple days since I'm working on
refactoring a multi-threaded GUI app at work and want to be sure it's
rock solid/thread-safe. I've seen all the posts about using BeginInvoke
to have worker threads interact with the UI. My question is this:

I created a plain old Windows Form application (VS.NET 2005) with a
blank form, built it (release build), ran it from Windows Explorer and
Task Manager claims the application is using four threads. What are
they? Obviously one is the main app/UI. What are the others?

Someone will be along shortly with a more in depth answer, but broadly
speaking: The objects of type System.Threading.Thread that application
developers are concerned with do *not* map one-to-one with the Win32
entities known as 'threads'. The latter is what Task Manager is telling
you about; the former are the things for which we have to have concern
for thread safety.

For background reading on this I would start with Richter ('CLR via
C#'), though there may well be even more advanced books specifically
about concurrent programming in .NET.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

The .NET threads are not phisically related to the one from win. For example
there is nothing like ThreadPool in native win.

At least one of those thread that you are seeing must be running the GC.

Take a look at this link ; it refers to the CF but I bet something similar
should apply to the full framework

Threads
There are up to four threads created by a .NET Compact Framework
application:

a.. A main application thread.

b.. A thread used to control various period timers and time-outs that can
be scheduled by the system or applications.

c.. A thread used to track changes to the active TCP/IP interfaces
(simulating the media sense behavior that is present on Windows XP but not
Windows CE).

d.. A thread that is used to run object finalizers. It is created when the
first finalizable object is garbage collected.

For more information about threading support, see Threading in the .NET
Compact Framework.



| I've been researching multi-threaded WinForms apps and thread
| synchronization stuff for a couple days since I'm working on
| refactoring a multi-threaded GUI app at work and want to be sure it's
| rock solid/thread-safe. I've seen all the posts about using BeginInvoke
| to have worker threads interact with the UI. My question is this:
|
| I created a plain old Windows Form application (VS.NET 2005) with a
| blank form, built it (release build), ran it from Windows Explorer and
| Task Manager claims the application is using four threads. What are
| they? Obviously one is the main app/UI. What are the others?
|
| I then added a Windows Timer control to the form and updated a label
| every second. Still four threads. I expected a timer to be on its own
| thread even though it posts "tick" events to the UI message
| loop/thread.
|
| I removed the Windows Timer and replaced it with a System Timer which
| runs "tick" events on a different thread, yet the thread count still
| stays at four. Huh?
|
| Is there a built-in thread pool with a few workers hanging around to do
| timers and stuff? What exactly is going on here?
| Are those extra threads part of the CLR doing its magic to run the EXE?
| Other?
|
| My next question will be how many threads remoting (inter-process on
| the same PC) adds to the mix. The UI app I'm refactoring makes use of
| several remote objects (running methods and receiving events with
| data). I'm guessing there is a thread for each proxy/socket to handle
| marshalling stuff. And the event handling from remote objects
| supposedly grabs a thread from the thread pool. Inquiring minds what to
| really KNOW what's going on under the hood.
|
| Pointers to good articles and/or books welcome. Spend the last weekend
| Googling and reading...
|
| Thanks!
|

 

[Willy Denoyette [MVP]]

I've been researching multi-threaded WinForms apps and thread
synchronization stuff for a couple days since I'm working on
refactoring a multi-threaded GUI app at work and want to be sure it's
rock solid/thread-safe. I've seen all the posts about using BeginInvoke
to have worker threads interact with the UI. My question is this:

I created a plain old Windows Form application (VS.NET 2005) with a
blank form, built it (release build), ran it from Windows Explorer and
Task Manager claims the application is using four threads. What are
they? Obviously one is the main app/UI. What are the others?

I then added a Windows Timer control to the form and updated a label
every second. Still four threads. I expected a timer to be on its own
thread even though it posts "tick" events to the UI message
loop/thread.

I removed the Windows Timer and replaced it with a System Timer which
runs "tick" events on a different thread, yet the thread count still
stays at four. Huh?

Is there a built-in thread pool with a few workers hanging around to do
timers and stuff? What exactly is going on here?
Are those extra threads part of the CLR doing its magic to run the EXE?
Other?

My next question will be how many threads remoting (inter-process on
the same PC) adds to the mix. The UI app I'm refactoring makes use of
several remote objects (running methods and receiving events with
data). I'm guessing there is a thread for each proxy/socket to handle
marshalling stuff. And the event handling from remote objects
supposedly grabs a thread from the thread pool. Inquiring minds what to
really KNOW what's going on under the hood.

Pointers to good articles and/or books welcome. Spend the last weekend
Googling and reading...

Thanks!

A managed application always starts with a minimum of 3 threads:
1 is the main thread
2 is the debugger thread
3 is the finalizer thread.

A Windows Forms application has at least one additional thread;
4 the GDI+ rendering thread.
Threads 1 and 3 are OS threads, associated with a logical (CLR) thread , while 2 and 4 are
just native OS threads created by the CLR, they don't have an associated logical thread.

Non "Windows Forms Timers" are handled by the Threadpool, more exactly their handlers run on
an IO completion thread pulled from the pool. It's obvious that you will only notice these
threads when they run for at least Taskman's window update interval .
Windows Forms Timer handlers are run on the UI thread, they are simple WM_TIMER handlers.

Willy.

 

[gsimmons]

Thanks for the replies folks. The help is much appreciated. I was
getting a little concerned when I see our application using 13 or 14
threads in Task Manager and I was (still am) trying to learn where
they're all coming from. I'll add some remoting to my stupid demo app
and see if I can figure out where in all that auto-magic proxy stuff
the threads are being used. I guess all I really need to know/care
about is:

- the UI runs on the main thread
- Windows.Form timer event handlers are on the UI thread
- System timers are on a thread pool thread
- Remote event handlers are on a thread pool thread
- BeginInvoke is your friend

but I like to understand what's going on under the hood too. Time to
dig out a box of books from the last job. I think Richters .NET
programming book is in there somewhere...

Garry