none
What is 'clr!CLRSemaphore::Wait' ? RRS feed

  • Question

  • Hello,

    I have several production dumps where client is reported to just hang. Based on 'some' analysis, There are several threads (almost 3 to 4) whose top of the stack is clr!CLRSemaphore::Wait?

    Can someone help in  understanding the construct? What does this operation account to the thread activity/health?

    I did not find any helpful documentation to help understand this kind of call stack.

    Thank you...


    Tuesday, August 6, 2013 5:48 PM

Answers

All replies

  • You'd have to see more of the call stack to be able to determine what's causing this.  clr!CLRSemaphore.Wait is an internal data structure that's used by the ThreadPool, amongst other things (it's an internal semaphore implementation).

    3-4 threads blocked on clr!CLRSemaphore.Wait could mean a lot of things, but aren't necessarily the problem (at least not without seeing more of the call stack).  Any time you have a thread pool thread that's been scheduled but not running yet, it will show up this way.  3 or 4 of these at a given time is pretty normal in a lot of environments.


    Reed Copsey, Jr. - http://reedcopsey.com - If a post answers your question, please click Mark As Answer on that post. If you find a post helpful, please click Vote as Helpful.

    Tuesday, August 6, 2013 6:03 PM
    Moderator
  • Are you familiar with what a Semaphore is?

    It sounds like you have some threads which are waiting for a resource to free up.

    Tuesday, August 6, 2013 6:12 PM
  • That's what i am trying to find out - what resource its waiting on.

    Tuesday, August 6, 2013 6:37 PM
  • That makes sense. I wonder if the background threads have already done their work and waiting for more work to be scheduled.

    Some of the other CLR threads are trying to execute some code in DllMain (change request have already been filed :) for that)

    Call stack doesn't really have much but here it is.

    KERNELBASE!WaitForSingleObjectEx+0x98, calling ntdll!NtWaitForSingleObject
    kernel32!WaitForSingleObjectExImplementation+0x75, calling KERNELBASE!WaitForSingleObjectEx
    clr!CLRSemaphore::Wait+0xbf
    KERNELBASE!SleepEx+0x91, calling KERNELBASE!_SEH_epilog4
    clr!EESleepEx+0x4f, calling kernel32!SleepExStub
    clr!ThreadpoolMgr::UnfairSemaphore::Wait+0x131, calling clr!CLRSemaphore::Wait
    KERNELBASE!NlsValidateLocale+0x10, calling KERNELBASE!CheckSpecialLocales
    clr!ThreadpoolMgr::WorkerThreadStart+0x2ed, calling clr!ThreadpoolMgr::UnfairSemaphore::Wait
    clr!Thread::intermediateThreadProc+0x4d
    clr!Thread::intermediateThreadProc+0x3b, calling clr!_alloca_probe_16
    kernel32!BaseThreadInitThunk+0xe
    ntdll!__RtlUserThreadStart+0x70
    ntdll!_RtlUserThreadStart+0x1b, calling ntdll!__RtlUserThreadStart

    Tuesday, August 6, 2013 6:41 PM
  • Tuesday, August 6, 2013 7:42 PM
    Moderator
  • That looks like the call stack of ThreadPool threads which are waiting for work items, but haven't been scheduled any.

    The first time a work item is queue'd up to the ThreadPool the ThreadPool always creates a minimum number of threads. On most systems I observe a minimum of 4.

    So while it may seem wasteful to spin up four threads when the entire program only makes one ThreadPool call, the ThreadPool isn't optimized for that scenario. It's tuned to perform well with programs which will be making thousands+ calls to it during the lifetime of the program.

    So I believe that Reed responded correctly with his first reply.

    Tuesday, August 6, 2013 10:43 PM
  • Hi Clean_Code_Striver,

    Welcome to the MSDN forum.

    I am writing to check the status of the issue on your side.What about this issue now?
    I will temporarily mark Read’s responses and Jared's response as an answer. You can unmark it if they provide no help.

    Thanks for Read’s responses and Jared's response at the same time.

    Have a nice day!

    Damon


    Damon Bu - MSFT
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, August 9, 2013 9:50 AM
  • I did find Concurrency Visualizer amazingly useful to find multi-threading bottlenecks and lock-ups.

    Thanks a lot Read, Jared.

    Friday, August 9, 2013 4:01 PM