First published on MSDN on Apr 07, 2016
One of the best parts of my job is that I get to learn something new each and everyday. This week I learned something completely new about deadlock monitor. Deadlock monitor grants locks, yes you read that correctly.
In a very small window the lock monitor prevents the releasing lock owner from directly granting lock ownership to the next owner/owners. Deadlock monitor loops over tasks and builds the blocking graph from locks and other deadlock monitor enabled objects. The graph allows deadlock monitor to detect the edges and loops indicating blocking or deadlocking. The outcome of the work is to resolve deadlocks or produce blocking information when ‘blocked process report’ events are enabled.
When deadlock monitor finds a task, blocked on a lock, the lock is marked as in-use by deadlock monitor. The lock owner can release the lock and continue execution but it is prevented from granting other tasks the lock. This behavior prevents the invalidation of the deadlock monitor graph. When deadlock monitor completes the cycle of checks the graph is destroyed. In the process of destroying the graph the object references are released and if the lock was released while deadlock monitor held it in the graph, deadlock monitor performs the deferred grant activities, waking the new owners.
Simply stated, if deadlock monitor holds a reference to a lock being released the ownership, in a sense, is transferred to deadlock monitor. Deadlock monitor issues the appropriate grants as needed at the end of the cycle.
Why after 21 years at Microsoft do I need to know this? Because a customer reported the following in sys.dm_exec_requests.
-
Session: 321
-
Blocking Session: 0
-
Wait Type: LCK_M_X
This is unusual as session 321 has become the head blocker but no blocking session exists and the current wait type is still LCK_M_X. This is exactly the state the lock looks like when the original session has completed its work with the lock (released the lock) and deadlock monitor is actively processing the graph. The lookup for blocking session finds no session blocking. Blocking session = 0 is reported but the lock has not been granted to session 321 so the wait type still indicates the proper wait for the session. The wait type is only cleared when the worker is signaled.
Bob Dorr - Principal Software Engineer SQL Server
