This will happen before any actual deadlocks occur.Įven if the conflicting code paths can never happen simultaneously, they should still be rewritten if they involve lock hierarchy violations. If you were to create a node for each resource, and draw an arrow any time one lock is acquired before another, then path loops would represent lock hierarchy violations.ĭriver Verifier will issue a bug check when one of these violations is discovered. To find potential deadlocks, Driver Verifier builds a graph of resource acquisition order and checks for loops. ![]() Most of the time, these violations identify code paths that will deadlock when given the chance. Effects of Deadlock Detectionĭriver Verifier's Deadlock Detection routines find lock hierarchy violations that are not necessarily simultaneous. It does not monitor the use of ERESOURCEs, nor does it monitor the use of nonowned resources. The Deadlock Detection option of Driver Verifier looks for potential deadlocks involving spin locks, mutexes, and fast mutexes. However, since these resources are not actually owned by any one thread, it is not possible to identify the delinquent thread with any degree of certainty. It is of course possible, and all too common, for code to misuse these resources in such a way that two threads will end up waiting indefinitely for each other to complete. Resources that are signaled rather than acquired (such as events and LPC ports) tend to cause much more ambiguous deadlocks. These include spin locks, mutexes, fast mutexes, and ERESOURCEs. The most unambiguous deadlocks are the result of owned resources. Lock hierarchy should be followed even when there is no possibility of a deadlock, since in the process of maintaining the code it will be easy for a deadlock to be accidentally introduced. ![]() This means that A must never be acquired after B or C, and B must not be acquired after C. If A is taken before B at one point and B before C at another, the hierarchy is A-B-C. Whenever it is necessary to have more than one lock acquired at a time, each lock should have a clear precedence. The common denominator among all deadlocks is that lock hierarchy is not respected. Single-thread deadlocks can occur when a thread attempts to take a lock that it already owns. However, the farther apart the lock acquisitions are, the more likely these become. These deadlocks require a certain degree of "bad luck" since they rely on a number of things happening simultaneously. Three-way deadlocks between three threads and three locks are common - and even five-part or six-part deadlocks occur occasionally. ![]() At best this causes the threads involved to halt, and at worst causes the system to stop responding.ĭeadlocks are not limited to two threads and two resources. If both sequences happen at the same time, Thread 1 will never get Lock B because it is owned by Thread 2, and Thread 2 will never get Lock A because it is owned by Thread 1. The most common form of deadlock occurs when two or more threads wait for a resource that is owned by the other thread. Causes of DeadlocksĪ deadlock is caused when two or more threads come into conflict over some resource, in such a way that no execution is possible. The Deadlock Detection option of Driver Verifier, along with the !deadlock kernel debugger extension, is an effective tool for making sure your code avoids poor use of these resources.ĭeadlock Detection is supported only in Windows XP and later versions of Windows. This Driver Verifier option will detect code logic that has the potential to cause a deadlock at some future point. Deadlock Detection monitors the driver's use of resources which need to be locked - spin locks, mutexes, and fast mutexes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |