.Net Profiler - Getting thread status from Profiler RRS feed

  • Question

  • I have set event masks  "COR_PRF_MONITOR_SUSPENDS" & "COR_PRF_MONITOR_THREADS" to get the thread creation and destroy callbacks. 

    I form stack trace from ThreadContext_start function for each thread till some depth from "FunctionEnter" hook.

    By some way i take the thread creation and cpu time, etc. I need to take the thread waiting status. 

    I will say the running threads and completed threads in a measure period. How can i say the waiting threads list.? 

    When a thread goes to waiting state in C#.? (Guess when it sleeps and when it is waiting for notification)

    There is RuntimeSuspend Callback, but i am not receiving that callback. What is the other way to get if the thread went to waiting state.? 

    Wednesday, April 5, 2017 5:25 AM

All replies

  • The RuntimeSuspend*/RuntimeResume* callbacks are for when the runtime as a whole is suspended/resumed (eg. for GC), it's not reporting when individual threads enter/leave the waiting state.

    I believe the CLR funnels most blocking operations through a core function in order to support SynchronizationContext.Wait; so in theory at least, it could provide notifications for those triggers. However if a thread blocks because it, say, pinvoked a native method that blocks, then the CLR would be unable to report it. So if the runtime provided such a callback, it would be incomplete and potentially misleading.

    Maybe there is a way to get this information through win32, but I wouldn't expect it to work in-process.

    Wednesday, April 5, 2017 11:14 AM
  • Do u mean, if that core function ( similar to ThreadContext_Start- which will be called on thread start) comes in FunctionEnter callback we can consider that the thread goes to waiting state. ?

    Wednesday, April 5, 2017 12:05 PM
  • No, that function is internal to the run-time; it's not managed and won't generate any callbacks. I'm suggesting that your goal is likely to be unobtainable through the profiler API. (though I'm not an authoritative source on this)

    If you only care about the time spent waiting for managed locks, then maybe you could look at when the thread enters/leaves Monitor.Enter and Monitor.Wait. I believe there is a post around here somewhere relating to someone trying to do something similar, IIRC they had some difficulty with one of the calls being inlined (the profiler is able to prevent methods from being inlined, but there will be a performance impact).

    Wednesday, April 5, 2017 9:58 PM