Detecting deadlocks in interop-debugging

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.