.NET Threading (& Windows threading)

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'd like to know how the CLR handles threading... I think the call to the
OS's Win32 method CreateThread() in C or C++ creates an operating system
thread with its own stack. But what does .NET do? Are managed threads
assigned an OS stack?

Also, I'm kind of amateurish with this stuff... so if there are some general
good threading resources (Windows and .NET) on the internet you could point
me to them?

Thanks

-Andrew
 
But what does .NET do? Are managed threads
assigned an OS stack?
Click to expand...

In v1.x the answer is yes, there's a 1:1 mapping between managed and
native threads.

v2.0 is a bit more flexible and gives a runtime host more control over
this, making it possible to use fibers instead.



Mattias
 
Fibers, which are lightweight threads, are also natively supported on
Windows 2000 and later. The answer would still be "yes", there's a 1 to 1
mapping between .NET threads and OS threads.

Mike Ober.
 
Thanks!

Michael D. Ober said:
Fibers, which are lightweight threads, are also natively supported on
Windows 2000 and later. The answer would still be "yes", there's a 1 to 1
mapping between .NET threads and OS threads.

Mike Ober.
Click to expand...
 
Michael D. Ober said:
Fibers, which are lightweight threads, are also natively supported on
Windows 2000 and later. The answer would still be "yes", there's a 1 to 1
mapping between .NET threads and OS threads.

Mike Ober.
Click to expand...

No there is not, you can have multiple logical threads assigned to the same
OS thread when they are mapped to fibers.


Willy.
 
So can the OS. A fiber is, at it's simplest, a thread that the OS can't
schedule. As such, it must have a parent thread that schedules it. Windows
allows multiple fibers to have the same parent thread. Thus, a .Net mapping
of a thread still maps to a single OS thread. A .Net mapping of a fiber
maps to a single OS fiber.

From MSDN:

"A fiber is a unit of execution that must be manually scheduled by the
application. Fibers run in the context of the threads that schedule them.
Each thread can schedule multiple fibers. In general, fibers do not provide
advantages over a well-designed multithreaded application. However, using
fibers can make it easier to port applications that were designed to
schedule their own threads."


=======
Ada does it's own thread scheduling, which is partly why the US DoD wanted
(note the past tense) to use Ada for weapons systems.

For what it's worth, there is a warning in the Beta 2 MSDN to not treat
pooled threads as OS threads. From reading this warning, it appears that
the managed thread pool actualy is a pool of OS fibers.
<http://msdn2.microsoft.com/library/ms182291(en-us,vs.80).aspx >

Mike.
 
As you stated correctly an OS thread can host multiple fibers, that means
that the managed threads A and B can be mapped on the same OS thread
through 2 different fibers, this is not what I would call a one to one
mapping but a many to one mapping.
The managed thread pool in v2.0 thread is NOT based on fibers, what's more,
the CLR doesn't know anything about fibers, they come into play when the CLR
is hosted, and it's the unmanaged host that must provide/manage the
threadpool based on fibers (a number of threads each hosting a number of
fibers).
That's exactly what SQL2005 does when hosting the CLR, it provides the
fibers based threadpool, the CLR doesn't use it's own implementation and
simply posts it's "workitems" to the host provided threadpool. This is what
the msdn2 page talks about.

Willy.
 
Back
Top