/*
You must also call BeginThreadAffinity before blocking on any .NET Framework type that inherits from WaitHandle, because these types depend on operating system objects.
*/
Can anyone verify this or clear this up
Thanks...
You must also call BeginThreadAffinity before blocking on any .NET Framework type that inherits from WaitHandle, because these types depend on operating system objects.
*/
Thread.BeginThreadAffinity required before WaitHandle calls?
Michael Iacoviello
Is the threading model an application configuration setting or in some way detectable by the runtime
TheCatty
As you alluded to, this method is when running in a hosted environment where the current threading model is set to fiber mode.
Currently, most of the time only SQL Server 2005 hosts the CLR in fiber mode. But, there's no guarentee that a stand-alone application will not be running in a CLR hosted in fiber mode. This method effectively does nothing if the host is not in fiber mode.
If you're not writing a completly fiber-safe application there's not much point in adding {Begin|End}ThreadAfinity around WaitHandle objects...
Caleb Widmer
Using fibers in a host is not supported by the .Net Framework 2.0.
Even without fibers, a host could move managed code from one Win32 Thread to another which could cause WaitHandle ownership issues.
Thanks!
Todd Reifsteck
SDET, .Net CLR
jrx
As far as I can tell, how the host implements threading is an implementation detail of the host. I can see no documented way of configuring the "standard" CLR host to use fibers instead of Win32 threads, or to query the host as to how it has implemented "threads".
If you want to be safe or support other hosted CLR environments like SQL Server, I would suggest using {Begin|End}ThreadAffinity.
It's extemely uncommon for programmers to use {Begin|End}ThreadAffinity in "normal" applications.
Anonymousandmad
http://msdn2.microsoft.com/en-us/library/ms228970.aspx
http://msdn2.microsoft.com/en-us/library/ms182291.aspx
http://msdn.microsoft.com/msdnmag/issues/05/06/HyperThreading/default.aspx
bugduc
Dino Viehland has an excellent blog that discusses fibers in the .Net Framework 2.0.
The specific article that mentions that the Framework no longer supports fibers is at http://blogs.msdn.com/dinoviehland/archive/2005/09/15/469642.aspx. This was a late decision in the 2.0 lifecycle and it is very possible that articles that had been written before ~June or July, 2005 still had references to fibers and managed code.
Steve-x