Ask a questionAsk a question
 

AnswerThe CLR's internal threads

  • Monday, November 02, 2009 5:39 PMDnptd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    It is known that the CLR creates additional threads for its owns needs like GC. Which tasks more may be executed by the CLR except GC? Is there an opportunity to recognize such internal threads inside CLR profiler?

    Thanks.

Answers

  • Tuesday, November 03, 2009 5:10 PMDavid BromanMSFT, OwnerUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    You can always break in to a managed app with a native debugger and peek at what threads are created and what stacks they have.  Some of the most common threads you'll see are the finalizer thread and a debugger helper thread.  GC can also create threads for its own use, and there are other reasons the CLR may need to create its own thread.

    Since profilers are native code, they get to view all the threads in the process simply by using OS APIs.  Your profiler may also end up running on some of these internal threads depending on what your profiler does.  For example, if your profiler responds to the Enter/Leave/Tailcall hooks, then your hooks will be called on the finalizer thread when a finalizer is executed.  If your profiler responds to GC events, and the GC creates extra threads to do its job (e.g., server-mode GC), then your profiler will be called on those GC threads.

    It's worth noting that CLR Profiling API events like ThreadCreated are specifically for managed threads only.  However, you get to write a DllMain, and can choose to respond to DLL_THREAD_ATTACH, which notifies you of any new OS threads being created for the process (native or managed).


    Thanks,
    Dave

All Replies

  • Monday, November 02, 2009 10:06 PMRay M_ Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    As far as i know its not officially documented anywhere but since rotor and the real runtime are pretty similar (but not identical) you could look into the rotor code to see what they spin off extra threads for to get an idea  of what the real runtime could be doing.

  • Tuesday, November 03, 2009 6:21 AMDnptd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Thank you for an idea.
  • Tuesday, November 03, 2009 5:10 PMDavid BromanMSFT, OwnerUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    You can always break in to a managed app with a native debugger and peek at what threads are created and what stacks they have.  Some of the most common threads you'll see are the finalizer thread and a debugger helper thread.  GC can also create threads for its own use, and there are other reasons the CLR may need to create its own thread.

    Since profilers are native code, they get to view all the threads in the process simply by using OS APIs.  Your profiler may also end up running on some of these internal threads depending on what your profiler does.  For example, if your profiler responds to the Enter/Leave/Tailcall hooks, then your hooks will be called on the finalizer thread when a finalizer is executed.  If your profiler responds to GC events, and the GC creates extra threads to do its job (e.g., server-mode GC), then your profiler will be called on those GC threads.

    It's worth noting that CLR Profiling API events like ThreadCreated are specifically for managed threads only.  However, you get to write a DllMain, and can choose to respond to DLL_THREAD_ATTACH, which notifies you of any new OS threads being created for the process (native or managed).


    Thanks,
    Dave