"Anthony Paul" <anthonypaulo@gmail.com> wrote in message
news:1173916027.252297.275360@e1g2000hsg.googlegroups.com...
> Hello everyone,
>
> I thought I has an excellent grasp on threading within the CLR (I've
> read "C# via the CLR" several times over) but I just went through
> "Essential .NET" and came across what are reffered to as "soft-
> threads". Now based on the little information on the subject, I
> presume that the "soft thread" is merely some sort of wrapper around
> an actual OS thread? If not, please correct me. I still don't
> understand why there was a need to create a "soft-thread" concept in
> the first place; why not just use the OS thread as-is? If anyone out
> there can offer some clarity on the subject I'd appreciate it.
>
> Regards,
>
> Anthony
>

>From this I take it that the "soft thread" is simply a sort of wrapper

"Anthony Paul" <anthonypaulo@gmail.com> wrote in message
news:1173983613.092727.231190@l77g2000hsb.googlegroups.com...
> 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!!
>
>>From this I take it that the "soft thread" is simply a sort of wrapper
> 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
>
>

> I've never heard of "Hard" or "Soft" threads before.
>
> I'm guessing that Hard threads are threads that have their lifetime
> managed by you, and that Soft Threads come from the various threadpools.
>
> The only other option would be Fibers, but any book that calls itself
> "Essential .Net" and talks about Fibers really needs to re-think it's
> title.
>
> --
> Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
> http://www.coversant.com/blogs/cmullins
>
> "Anthony Paul" <anthonypaulo@gmail.com> wrote in message
> news:1173916027.252297.275360@e1g2000hsg.googlegroups.com...
>> Hello everyone,
>>
>> I thought I has an excellent grasp on threading within the CLR (I've
>> read "C# via the CLR" several times over) but I just went through
>> "Essential .NET" and came across what are reffered to as "soft-
>> threads". Now based on the little information on the subject, I
>> presume that the "soft thread" is merely some sort of wrapper around
>> an actual OS thread? If not, please correct me. I still don't
>> understand why there was a need to create a "soft-thread" concept in
>> the first place; why not just use the OS thread as-is? If anyone out
>> there can offer some clarity on the subject I'd appreciate it.
>>
>> Regards,
>>
>> Anthony
>>
>
>

On Mar 15, 5:29 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
> The point he's making is true, but mostly irrelevant. As a day-to-day
> programmer, even one who does multi-threaded stuff all day long, it's just
> doesn't matter.
>
> Yes, the reality is that CLR threads are mapped (by the CLR host) to O/S
> threads. The O/S then schedules it's threads, and everything runs just fine.
>
> The potential is there for the CLR host to break this 1:1 mapping, and do
> something more creative. Originally the SQL 2005 CLR host was going to do
> that, but they have abandoned that as it caused too many issues.
>
> At this point in time, and for the forseeable future, it's a moot point, and
> the distinction between "hard & soft threads" can be ignored.
>
> --
> Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVPhttp://www.coversant.com/blogs/cmullins
>