Detecting deadlocks in interop-debugging

• US 7,917,909 B2
• Filed: 05/23/2006
• Issued: 03/29/2011
• Est. Priority Date: 05/23/2006
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Stall, Jonathon Michael
• Primary Examiner(s): Zhen; Li B
• Assistant Examiner(s): JORDAN, KIMBERLY L
• Application Number:
  US11/419,965
• Publication Number:
  US 20070288939A1
• Time in Patent Office: 1,771 Days
• Field of Search: None
• US Class Current: 718/106
• CPC Class Codes: G06F 11/3632 of specific synchronisation aspects
• CPC Class Codes: G06F 9/524 Deadlock detection or avoidance

Abstract

A method and system for implementing detecting deadlocks in interop-debugging is described herein. One or more synchronization objects that an application program interface (API) could block on are identified. A canary thread that takes one or more of the synchronization objects is created. The canary thread is called to take the one or more synchronization objects. If the canary thread returns within a predetermined timeout period, then the one or more synchronization objects are available and safe to take. If the canary thread does not return within the predetermined timeout period, then the one or more synchronization objects may not be available.

Claims

1. A computer-implemented method comprising:

identifying one or more synchronization objects that an application program interface (API) could block on;

responsive to receiving a debugger request for a helper thread, creating, by the helper thread, a canary thread, wherein;

the canary thread attempts to take and release the one or more synchronization objects, and

the one or more synchronization objects are takeable by the helper thread in response to the debugger request;

determining whether the canary thread exits and returns to the helper thread within a predetermined timeout period; and

,

when the canary thread exits and returns to the helper thread within the predetermined timeout period, determining that the one or more synchronization objects are free to take; and

when the canary thread does not exit and return to the helper thread within the predetermined timeout period, returning a graceful failure from the helper thread without trying to take the one or more synchronization objects.

2. The method of claim 1, wherein the canary thread takes the one or more synchronization objects directly.

3. The method of claim 1, wherein the canary thread takes the one or more synchronization objects indirectly.

4. The method of claim 1, wherein the one or more synchronization objects include one or more locks.

5. The method of claim 1, wherein the one or more synchronization objects include one or more mutexes.

6. The method of claim 1, wherein the one or more synchronization objects include one or more monitors.

7. The method of claim 1, wherein the one or more synchronization objects include one or more signable events.

8. The method of claim 1, wherein the one or more synchronization objects include one or more semaphores.

9. One or more device-readable storage media with device-executable instructions stored thereon which, when executed by a processing unit, perform:

identifying one or more synchronization objects that an application program interface (API) could block on;

responsive to receiving a debugger request for a helper thread, calling, by the helper thread, a canary thread, wherein the canary thread attempts to both take and release the one or more synchronization objects before returning to the helper thread;

counting when the one or more synchronization objects are taken and released based on the attempts by the canary thread;

determining whether the one or more synchronization objects are free to take, based on the counting; and

when the counting does not indicate that the one or more synchronization objects are free to take, returning a graceful failure from the helper thread without trying to take the one or more synchronization objects.

10. The device-readable storage media according to claim 9, further comprising device-executable instructions which, when executed by the processing unit, perform:

reusing the canary thread across a plurality of synchronized states.

11. The device-readable storage media according to claim 9,

wherein counting includes updating, by the canary thread, at least one global counter accessible to both the canary thread and the helper thread;

and further comprising device-executable instructions which, when executed by the processing unit, perform;

determining, by the helper thread, whether the one or more synchronization objects are free to take based on the at least one global counter that is updated by the canary thread.

12. The device-readable storage media according to claim 9, wherein the canary thread takes the one or more synchronization objects directly.

13. The device-readable storage media according to claim 9, wherein the canary thread takes the one or more synchronization objects indirectly.

14. The device-readable storage media according to claim 9, wherein the one or more synchronization objects comprise locks, mutexes, monitors, signable events, or semaphores.

15. A system comprising:

a helper thread;

a canary thread; and

a processing unit configured to execute the canary thread and the helper thread;

the helper thread being configured to;

identify one or more synchronization objects that may be taken by the canary thread; and

create the canary thread;

the canary thread being configured to;

attempt to take and release the one or more synchronization objects; and

exit and return to the helper thread after releasing the one or more synchronization objects;

the helper thread being further configured to;

determine whether the canary thread exits and returns to the helper thread within a predetermined timeout period;

when the canary thread exits and returns to the helper thread within the predetermined timeout period, determine that the one or more synchronization objects are free to take; and

when the canary thread does not exit and return to the helper thread within the predetermined timeout period, determine not to take the one or more synchronization objects.

16. The system according to claim 15, wherein the canary thread takes the one or more synchronization objects directly.

17. The system according to claim 15, wherein the canary thread takes the one or more synchronization objects indirectly.

18. The system according to claim 15, wherein the one or more synchronization objects comprise locks, mutexes, monitors, signable events, or semaphores.