Potential deadlock caused by an infinite wait

This tutorial demonstrates how to use Thread Validator to identify a potential deadlock involving an infinite wait. Thread Validator cannot make this judgement itself as the decision that a potential deadlock can occur is a matter of judgement for the software engineer debugging this issue.

Note that for your executing nativeExample your critical section addresses, thread Ids and sequence numbers will all be different. We have used the values that we experienced to write this tutorial. Substitute your own values where appropriate.

• Launch the sample application. Click on the re-launch icon on the toolbar.
  
• The previously launched application is started.
• From the Test menu, choose the Start 2 thread deadlock with infinite wait.
• Viewing the Locks tab shows one critical section is contended and that a wait is in progress. It can be seen that the wait timeout is set to INFINITE. It can also be seen that the locked critical section Lock count is not changing, neither is the contention count for the critical section.
  
• Viewing the Per Thread Locks tab shows that the context switch counts for both thread 359 and thread 340 are not changing whilst the context switch counts for other threads are changing. Thread 340 has locked a critical section and is also involved in a wait with an INFINITE timeout. Thread 359 is waiting on the same critical section that is locked by thread 340. Both entries for the same critical section are yellow, indicating that the critical section is contended by thread 359 against thread 340.
  
• Viewing the Current Locks tab shows that the context switch counts for both thread 359 and thread 340 are not changing whilst the context switch counts for other threads are changing. Thread 340 has locked a critical section and is also involved in a wait with an INFINITE timeout. Thread 359 is waiting on the same critical section that is locked by thread 340. Both entries for the same critical section are yellow, indicating that the critical section is contended by thread 359 against thread 340.
  
• The sequence IDs for each of these entries indicates the order in which each action occurred. The first action was the acquiring of the critical section by thread 340 (sequence 16543). The second action was the attempt to acquire the same critical section by thread 359 (sequence 16587). The critical section was already owned causing the thread scheduler to switch threads, resulting in thread 340 running. The last actions was the waiting on the thread handle of thread 359 with an infinite wait (sequence 16588). Because thread 340 is waiting for thread 359 to terminate and thread 359 is waiting for thread 340 to release the critical section, both threads wait for each other forever (unless either thread is terminated).
• Using the Current Locks tab, right click on the yellow entry for the locked critical section of thread 340 and choose Show Callstack…. A modeless dialog containing the callstack for the lock is shown.
  
• Repeat this for the blue entry for the infinite wait of thread 340.
  
• Repeat this for the yellow entry for the locked critical section of thread 359.
  
• Inspecting the callstacks for the three potential deadlocks confirms the potential deadlock.
• Close the Application using the File menu’s Exit command.
• The various tabs will display the last known state of the critical sections and waits prior to the application finishing.
• Any errors identified during shutdown will be added to the state for each critical section and the displays updated to reflect this.