Thread.BeginThreadAffinity required before WaitHandle calls?

MSDN doc for this method has this interesting statement in remarks:

/*

You must also call BeginThreadAffinity before blocking on any .NET Framework type that inherits from WaitHandle, because these types depend on operating system objects.

*/

It is not clear to me if this statement is only in context with MSSQL Server's hosting enviroment or if it is required in any CLR host.

Can anyone verify this or clear this up

Thanks...




Answer this question

Thread.BeginThreadAffinity required before WaitHandle calls?

  • Michael Iacoviello

    Thanks Peter.

    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

    Todd Reifsteck - MSFT wrote:
    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.

    What framework is SQL Server 2005 using then. MSDN describes several places where it uses fibers for managed threads in "fiber mode":

    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

    j_e_f_f wrote:
    Is the threading model an application configuration setting or in some way detectable by the runtime
    I'm still trying to track that down.

  • Thread.BeginThreadAffinity required before WaitHandle calls?