CLR threads vs Windows thread

[Kursat]

Hi All,

Once I read an article about threading in .NET and the author was saying
that there is no one to one relationship between CLR threads and native
Windows threads. His claim was CLR implements managed threads as Windows
Fibers and can schedule them independently from OS scheduler. Now I am
reading "CLR via C#" by Jeffrey Richter and I always trust his deep
knowledge about Microsoft technologies. At the end of page 621 he says
"After all, CLR threads are Windows threads; which means that Windows
schedules and controls the synchronization of threads". I am confused now.
Do you have any ideea on this? Is there any implementation change related to
this between .NET versions?

Thanks in advance.

 

[Peter Duniho]

Hi All,

Once I read an article about threading in .NET and the author was saying
that there is no one to one relationship between CLR threads and native
Windows threads.

There is no guarantee of a one-to-one relationship, that's true.

His claim was CLR implements managed threads as Windows
Fibers and can schedule them independently from OS scheduler. Now I am
reading "CLR via C#" by Jeffrey Richter and I always trust his deep
knowledge about Microsoft technologies. At the end of page 621 he says
"After all, CLR threads are Windows threads; which means that Windows
schedules and controls the synchronization of threads". I am confused now.
Do you have any ideea on this? Is there any implementation change related to
this between .NET versions?

My understanding is that it's actually a difference between platforms,
not .NET version numbers. If I recall correctly, .NET on workstation
systems does currently have a one-to-one managed to unmanaged thread
relationship, but that on servers it doesn't (and could be using fibers,
but I don't know for sure).

The bottom line is that your code should not depend on the one-to-one
relationship. It's an implementation detail that could easily change in
future versions of .NET, and is already variable according at least to
where the managed code is running.

Pete

 

[Arne Vajhøj]

Once I read an article about threading in .NET and the author was saying
that there is no one to one relationship between CLR threads and native
Windows threads. His claim was CLR implements managed threads as Windows
Fibers and can schedule them independently from OS scheduler. Now I am
reading "CLR via C#" by Jeffrey Richter and I always trust his deep
knowledge about Microsoft technologies. At the end of page 621 he says
"After all, CLR threads are Windows threads; which means that Windows
schedules and controls the synchronization of threads". I am confused now.
Do you have any ideea on this? Is there any implementation change related to
this between .NET versions?

I can not find any indication that a .NET thread should be Windows
fibers.

The CLI specs say:

The logical abstraction of a thread of control is captured by an
instance of the System.Threading.Thread
object in the class library.

The framework docs say:

An operating-system ThreadId has no fixed relationship to a managed
thread, because an unmanaged host can control the relationship between
managed and unmanaged threads. Specifically, a sophisticated host can
use the CLR Hosting API to schedule many managed threads against the
same operating system thread, or to move a managed thread between
different operating system threads.

Which indicates that you should not assume a 1:1 relationship
between CLR threads and Windows threads.

I am rather sure that all current .NET version will map 1:1 though.

So I think the answer is:
- no fibers involved
- standard allows 1 to many CLR threads per OS thread
- current .NET implementations map 1 CLR thread to one OS thread

Arne

 

[Arne Vajhøj]

I would read this as "a sophisticated host can use the CLR Hosting API
to schedule many managed threads" as fibers on "the same operating
system thread". In other words, CLR threads can be fibers or they can be
OS threads or they can be something else entirely.

Multiple CLR threads per Windows thread does not necessarily
imply fibers - at least not fibers as in CreateFiberEx.

It would not even be easy to get transparent thread behavior
using cooperative schedules fibers.

Apparently they did try implementing it, but had to giv eup
due to various problems according to:

http://www.bluebytesoftware.com/blog/PermaLink,guid,2d0038b5-7ba5-421f-860b-d9282a1211d3.aspx

Arne

 

[Arne Vajhøj]

Interesting blog. It hints at the underlying issue of the complexity of
close to 20 years of patching and extending the Win32 API. Windows NT
3.1 went RTM over 17 years ago and it took MS a couple of years to write
it. The real question MS needs to consider is "Are the Win32 and Win64
APIs maintainable or should they be frozen and hosted by a newer or more
robust OS such as a true managed OS?"

I have always assumed that MS eventually would switch from:

CLR app native app
..NET lib
******* Win32 lib ******
******* NT lib *********

to:

CLR app native app
Win32 lib
******** .NET lib ******
******** ?? lib ********

But:
1) it would be a huge task (possible bigger than XP->Vista)
2) it is not very clear to me how a reverse p/invoke would work

Remember, Digital Equipment
Corporation released VMS, which is a fully managed OS, in the 1970s, so
we know it's doable.

????

The managable M in VMS just mean virtual memory like Windows (NT family)
and Unix/Linux also have - there are no garbage collection etc..

Arne