(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)
From the BOL description and call stack below, my guess is that the deadlock monitor’s search may be interrupted in some way if the sys.dm_os_waiting_tasks DMV is calculating the blocking_session_id for its output, so they synchronize on this mutex so only one or the other can be running at any time.
(Books Online description: “Occurs when the deadlock monitor and sys.dm_os_waiting_tasks try to make sure that SQL Server is not running multiple deadlock searches at the same time.”)
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:
Removed in SQL Server version:
Extended Events wait_type value:
The map_key value in sys.dm_xe_map_values is 261 in 2008 and 2008 R2, 268 in 2012, and 275 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.
I have not seen this wait type be a noticeable contention point.
Known occurrences in SQL Server (list number matches call stack list):
- Running the sys.dm_os_waiting_tasks DMV
Abbreviated call stacks (list number matches known occurrences list):