(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

RESOURCE_SEMAPHORE_MUTEX

(Back to main page…)

Description:

This wait type is when a thread is waiting for access to a critical section of code (one which only one thread can be executing) while attempting to acquire the resources needed to start compiling or executing a query. After the mutex has been acquired, if the attempt fails, the mutex is released and either a THREADPOOLRESOURCE_SEMAPHORE_QUERY_COMPILE, RESOURCE_SEMAPHORE_SMALL_QUERY, or RESOURCE_SEMAPHORE wait happens before the thread tries again.

(Books Online description: “Occurs while a query waits for its request for a thread reservation to be fulfilled. It also occurs when synchronizing query compile and memory grant requests.”)

Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.

Added in SQL Server version:

Pre-2005/2005

Removed in SQL Server version:

N/A

Extended Events wait_type value:

The map_key value in sys.dm_xe_map_values is 269 in 2008 and 2008 R2, 276 in 2012, and 283 in 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.

Other information:

I have not seen this wait type be a noticeable contention point. Troubleshooting should focus on the wait for the resource that could not be acquired (see the description above).

Known occurrences in SQL Server (list number matches call stack list):

  1. Waiting for the mutex (in this case, while trying to acquire a query execution memory grant)
  2. Waiting for the mutex (in this case, while releasing a query execution memory grant)

And other similar call stacks.

Abbreviated call stacks (list number matches known occurrences list):

  1. SOS_Task::PostWait+9e
    UnfairRecursiveMutexInternal<PaddedSpinlock<SuspendQueueSLock>,0>::LongWait+168
    TAutoMutex<UnfairRecursiveMutexInternal<PaddedSpinlock<SuspendQueueSLock>,0>,4294967295>::GetAccess+127
    ResourceSemaphore::Acquire+f7
    CQryMemQueue::CbufAcquireGrant+50a
    CQueryResourceGrantManager::AcquireGrant+7c6
    CQueryScan::Setup+180
    CQuery::CreateExecPlan+9d
    CXStmtQuery::SetupQueryScanAndExpression+268
    CXStmtQuery::InitForExecute+34
    CXStmtQuery::ErsqExecuteQuery+36d
    CXStmtSelect::XretExecute+2e7
    CMsqlExecContext::ExecuteStmts<1,1>+427
    CMsqlExecContext::FExecute+a43
    CSQLSource::Execute+86c
    process_request+a57
    process_commands+4a3
    SOS_Task::Param::Execute+21e
    SOS_Scheduler::RunTask+ab
  2. SOS_Task::PostWait+9e
    UnfairRecursiveMutexInternal<PaddedSpinlock<SuspendQueueSLock>,0>::LongWait+168
    TAutoMutex<UnfairRecursiveMutexInternal<PaddedSpinlock<SuspendQueueSLock>,0>,4294967295>::GetAccess+127
    ResourceSemaphore::Release+5f
    CQryMemQueue::ReleaseGrant+f2
    CQueryResourceGrantManager::ReturnGrant+17a
    CQueryScan::DestroyQuery+23f
    CXStmtQuery::ShutdownNormal+f3
    CXStmtQuery::ErsqExecuteQuery+cf7
    CXStmtSelect::XretExecute+2e7
    CMsqlExecContext::ExecuteStmts<1,1>+427
    CMsqlExecContext::FExecute+a43
    CSQLSource::Execute+86c
    process_request+a57
    process_commands+4a3
    SOS_Task::Param::Execute+21e
    SOS_Scheduler::RunTask+ab