Okay, here's an excerpt from "Essential .NET" regarding soft vs hard
threads (page 254, please excuse any typos, they are bound to be mine
and not the authors') :

<EXCERPT>
It is difficult to talk about processes without quickly steering the
conversation to the topic of threads. The CLR has its own abstraction
for modeling the execution of code that is conceptually similar to an
OS thread. The CLR defines a type, System.Threading.Thread, that
represents a schedulable entity in an AppDomain. A
System.Threading.Thread thread object is sometimes referred to as a
"soft thread" because it is a construct that is not recognized by the
underlying operating system. In contrast, OS threads are referred to
as "hard threads" because they are what the OS deals with.

There is NO ONE-TO-ONE RELATIONSHIP BETWEEN HARD THREADS AND CLR SOFT
THREAD objects. However, certain realities are known to be true based
both on the programming model and empirical analysis of the current
CLR implementation. For one thing, a CLR soft thread object resides in
exactly one AppDomain. ... Second, a given AppDomain may have multiple
soft thread objects. In the current implementation, this happens when
two or more hard threads execute code in a single AppDomain. All other
assumptions about the relationship between hard and soft threads are
implementation-specific.

In the current implemenation of the CLR, a given hard thread will have
at most one soft thread object affiliated with it for a given
AppDomain. Also, if a hard thread winds up executing code in multiple
AppDomains, each AppDomain will have a distinct soft thread object
affiliated with that thread. However, a hard thread never enters a
given AppDomain, then that AppDomain will not have a soft thread
object that represents the hard thread.

Finally, each time a given hard thread enters an AppDomainm it gets
the same soft thread object...

The CLR maintains a fair amout of information inside the hard thread's
thread local storage (TLS). In particular, one can find hard TLS
references to the current AppDomain and soft thread object. When a
hard thread crosses over from one AppDomain to another, the CLR
automatically adjusts these references to point to the new "current"
AppDomain and soft thread. The current implenetation of the CLR
maintains a per-AppDomain thread table to ensure that a given hard
thread is afiliated with only one soft thread object per AppDomain.

It is worth noting that a soft thread object has its own private
thread local storage that is accesible via the Thread.GetData and
Thread.SetData methods. Because this TLS is bound to the soft thread
object, when a hard thread crosses the AppDomain boundaires, it cannot
see the soft TLS that was stored while the hard thread was executing
in the previous AppDomain.

... As a point of interest, one can extract the current soft thread
object from the hard thread's TLS via the Thread.CurrentThread
property...
</EXCERPT>

This is basically all the information there is regarding soft-threads.
I haven't been able to find any more references to it anywhere. If
anybody has more details to share, please, do so!!

around a "hard thread" to prevent .NET developers from accessing the
hard thread directly. What confuses me, however, is that he states
that there is no one-to-one relationship between hard threads and soft
threads. Would anyone care to clarify this relationship or lack
thereof?

Regards,

Anthony

Or maybe CLR threads (soft?) vs. OS Threads (hard?). Strange terms for me
anyway.

Some good readings about CLR threading:

http://bdn1.borland.com/article/borcon/files/3176/paper/3176.html
http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspx
http://msdn.microsoft.com/msdnmag/issues/06/09/clrinsideout/default.aspx