Mechanisms to detect priority inversion

• US 8,689,223 B2
• Filed: 11/18/2008
• Issued: 04/01/2014
• Est. Priority Date: 11/18/2008
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Dadhich, Pankaj K., Lakkimsetti, Sravan K.
• Primary Examiner(s): LI, AIMEE J
• Application Number:
  US12/273,033
• Publication Number:
  US 20100125848A1
• Time in Patent Office: 1,960 Days
• Field of Search: 718/103, 718/104, 718/105, 712/214, 712/227
• US Class Current: 718/103
• CPC Class Codes: G06F 11/3632 of specific synchronisation aspects

Abstract

A method, computer program product, and device are provided for detecting and identifying priority inversion. A higher priority thread and a lower priority thread are received. A debugging application for debugging is executed. The lower priority thread requests and holds a resource. A break point is hit by the lower priority thread. The lower priority thread is preempted by the higher priority thread, and debugging stops until the higher priority thread completes. The higher priority thread requests the resource being held by the lower priority thread. It is determined whether priority inversion occurs.

Claims

1. A method for identifying priority inversion, comprising:

receiving a higher priority thread;

receiving a lower priority thread;

executing a debugging application for debugging;

requesting and holding a resource by the lower priority thread;

hitting a break point by the lower priority thread;

preempting the lower priority thread by the higher priority thread, wherein debugging stops until the higher priority thread completes;

requesting, by the higher priority thread, the resource being held by the lower priority thread; and

determining whether priority inversion occurs;

wherein a priority of the higher priority thread and the lower priority thread are configured to be changed during a debug mode;

associating break point priority to the higher priority thread, a middle priority thread, and to the lower priority thread, in which when the higher priority thread hits its high priority breakpoint, the high priority break point causes all lower priority threads to break including the middle priority thread and the lower priority thread;

wherein when the middle priority thread hits its middle priority break point, the lower priority thread breaks while the higher priority thread continues running to identify priority inversion.

2. The method of claim 1, wherein the resource is not available for the higher priority thread, and

wherein the higher priority thread goes to wait;

wherein a default priority for the break point priority is according to a corresponding priority of an associated thread.

3. The method of claim 2, further comprising:

detecting that priority inversion has occurred by recognizing that the higher priority thread is waiting for the resource being held by the lower priority thread.

4. The method of claim 2, wherein the higher priority thread is unsuccessful in the high priority thread'"'"'s request for the resource because the lower priority thread continues to hold the resource.

5. The method of claim 1, wherein the higher priority thread does not complete since the resource is being held by the lower priority thread.

6. The method of claim 1, wherein the lower priority thread does not release the resource.

7. The method of claim 1, wherein the lower priority thread requests and holds the resource after entering a critical section.

8. A computer program product, tangibly embodied on a non-transitory computer readable medium, for identifying priority inversion, the computer program product including instructions for causing a computer to execute a method, comprising:

receiving a higher priority thread;

receiving a lower priority thread;

executing a debugging application for debugging;

requesting and holding a resource by the lower priority thread;

hitting a break point by the lower priority thread;

preempting the lower priority thread by the higher priority thread, wherein debugging stops until the higher priority thread completes;

requesting, by the higher priority thread, the resource being held by the lower priority thread; and

determining whether priority inversion occurs;

wherein a priority of the higher priority thread and the lower priority thread are configured to be changed during a debug mode;

associating break point priority to the higher priority thread, a middle priority thread, and to the lower priority thread, in which when the higher priority thread hits its high priority breakpoint, the high priority break point causes all lower priority threads to break including the middle priority thread and the lower priority thread;

wherein when the middle priority thread hits its middle priority break point, the lower priority thread breaks while the higher priority thread continues running to identify priority inversion.

9. The computer program product of claim 8, wherein the resource is not available for the higher priority thread, and

wherein the higher priority thread goes to wait.

10. The computer program product of claim 9, further comprising:

detecting that priority inversion has occurred by recognizing that the higher priority thread is waiting for the resource being held by the lower priority thread.

11. The computer program product of claim 9, wherein the higher priority thread is unsuccessful in the high priority thread'"'"'s request for the resource because the lower priority thread continues to hold the resource.

12. The computer program product of claim 8, wherein the higher priority thread does not complete since the resource is being held by the lower priority thread.

13. The computer program product of claim 8, wherein the lower priority thread does not release the resource.

14. The computer program product of claim 8, wherein the lower priority thread requests and holds the resource after entering a critical section.

15. A computing device configured to identify priority inversion, the computer comprising:

a processor;

memory coupled to the processor, an application being resident in the memory and executing on the processor, the application comprising instructions to cause the processor to;

receive a higher priority thread;

receive a lower priority thread;

execute a debugging application for debugging;

request and hold a resource by the lower priority thread;

hit a break point by the lower priority thread;

preempt the lower priority thread by the higher priority thread, wherein debugging stops until the higher priority thread completes;

request, by the higher priority thread, the resource being held by the lower priority thread; and

determine whether priority inversion occurs;

wherein a priority of the higher priority thread and the lower priority thread are configured to be changed during a debug mode;

associating break point priority to the higher priority thread, a middle priority thread, and to the lower priority thread, in which when the higher priority thread hits its high priority breakpoint, the high priority break point causes all lower priority threads to break including the middle priority thread and the lower priority thread;

wherein when the middle priority thread hits its middle priority break point, the lower priority thread breaks while the higher priority thread continues running to identify priority inversion.

16. The computing device of claim 15, wherein the resource is not available for the higher priority thread, and

wherein the higher priority thread goes to wait.

17. The computing device of claim 16, further comprising:

detecting that priority inversion has occurred by recognizing that the higher priority thread is waiting for the resource being held by the lower priority thread.

18. The computing device of claim 16, wherein the higher priority thread is unsuccessful in the high priority thread'"'"'s request for the resource because the lower priority thread continues to hold the resource.

19. The computing device of claim 15, wherein the higher priority thread does not complete since the resource is being held by the lower priority thread.

20. The computing device of claim 15, wherein the lower priority thread does not release the resource.