From: not_a_commie on
The Thread class in .Net is not a true thread. It's more like a work
queue array in the CLR. To make a true thread in C# you have to make a
new AppDomain. The CLR pushes methods targeted for a specific
System.Thread into the real threads that it manages. And it doesn't
swap them out in the middle of an increment operation. It's not that
stupid.

Go read through this thread for more info:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/8072068926ec0a8/995c7921d4b8e436?lnk=gst&q=not_a_commie+monitor#995c7921d4b8e436
From: Peter Duniho on
not_a_commie wrote:
> The Thread class in .Net is not a true thread.

Architecturally speaking, that's correct. Practically speaking, not as
much.

> It's more like a work queue array in the CLR.

In current .NET implementations I'm aware of, threads are implemented
either as true threads or fibers. I'm not even sure what you mean by
"work queue array" � it's not a standard phrase I'm familiar with, nor
one that Google is familiar with � but a .NET thread is in fact very
much like a thread in either implementation (and of course exactly like
one where true threads are used).

> To make a true thread in C# you have to make a
> new AppDomain.

Not true. You can use the unmanaged GetCurrentThreadId() function to
verify that on the workstation (i.e. non-server) .NET versions, when you
create a new thread, you get a new OS thread.

In any case, the threading model in .NET is well-defined and in that
model, the "thread" .NET provides is every bit as much as "real thread"
as an OS thread would be, even when they are different.

> The CLR pushes methods targeted for a specific
> System.Thread into the real threads that it manages. And it doesn't
> swap them out in the middle of an increment operation. It's not that
> stupid.

..NET doesn't do anything special with an increment operation. It
depends on how the increment is implemented by the JIT compiler. If it
uses the "inc" instruction, then a context switch isn't possible during
the increment. But if it uses "mov", "add", "mov" then the increment
can be interrupted during the operation.

In any case, .NET doesn't provide any _guarantees_ about how it will
implement an increment. C# statements like "i++", "++i", "i = i + 1",
etc. all _must_ be protected with some kind of synchronization if the
variable "i" is accessed by multiple threads.

Pete