METHODS, APPARATUS AND ARTICLES OF MANUFACTURE FOR REGAINING MEMORY CONSISTENCY AFTER A TRAP VIA TRANSACTIONAL MEMORY

• US 20090217018A1
• Filed: 02/26/2008
• Published: 08/27/2009
• Est. Priority Date: 02/26/2008
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: ABRASHKEVICH, ALEXANDER, Heller, Thomas J. JR., Huras, Matthew A., Wilding, Mark F., Abrashkevich, Dmitri, Srivastava, Yogendra K., Blainey, Robert J., Munireddy, Sridhar
• Granted Patent: US 8,032,736 B2
• Time in Patent Office: Days
• US Class Current: 712/244
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 9/467 Transactional memory G06F9/528 takes precedence

Abstract

Embodiments of the invention provide a method for regaining memory consistency after a trap via transactional memory. Transactional memory and a transactional memory log are used to undo changes made to memory from a transaction start point up to the point of a trap event. After the trap event is processed, and the changes are rolled back, the program can resume execution at the beginning of the transaction.

Claims

1. A method for regaining memory consistency after a trap event, comprising:

initiating, by a first thread, a transaction, wherein the transaction includes a plurality of instructions;

recording a sequence of changes made to memory while executing the plurality of instructions;

detecting the occurrence of a trap event prior to completing the transaction;

rolling back the sequence of changes made to the memory up to a first instruction of the transaction, based on the recorded sequence, and

resuming execution of the thread at the first instruction of the transaction.

2. The method of claim 1, further comprising, and prior to resuming execution of the thread at the first instruction of the transaction, invoking a trap-handler associated with the detected trap event.

3. The method of claim 1, further comprising:

determining whether the transaction has been initiated and rolled back, on the basis of a detected trap event, more than a specified a number of times; and

terminating the first thread if the number of interruptions has exceeded a predetermined threshold.

4. The method of claim 1, wherein the transactional memory is software-based transactional memory.

5. The method of claim 1, wherein the transactional memory is hardware-based transactional memory.

6. The method of claim 1, wherein the trap event is generated in response to one of an invalid memory reference, a divide-by-zero error, a hardware event, and a user-generated interrupt.

7. The method of claim 1, wherein plurality of instructions included in the transaction represent an atomic sequence of steps that should either each be performed without interruption or the transaction aborted.

8. The method of claim 1, further comprising, prior to the execution of the thread at the first instruction of the transaction being resumed, passing an error code to the thread indicating a cause of the trap event.

9. A computer-readable storage medium containing a program, which, when executed performs an operation for regaining memory consistency after a trap event, the operation comprising:

initiating, by a first thread, a transaction, wherein the transaction includes a plurality of instructions;

recording a sequence of changes made to memory while executing the plurality of instructions;

detecting the occurrence of a trap event prior to completing the transaction;

rolling back the sequence of changes made to the memory up to a first instruction of the transaction, based on the recorded sequence; and

resuming execution of the thread at the first instruction of the transaction.

10. The computer-readable storage medium of claim 9, wherein the operation further comprises, and prior to resuming execution of the thread at the first instruction of the transaction, invoking a trap-handler associated with the detected trap event.

11. The computer-readable storage medium of claim 9, wherein the operation further comprises:

determining whether the transaction has been initiated and rolled back, on the basis of a detected trap event, more than a specified a number of times; and

terminating the first thread if the number of interruptions has exceeded a predetermined threshold.

12. The computer-readable storage medium of claim 9, wherein the transactional memory is software-based transactional memory.

13. The computer-readable storage medium of claim 9, wherein the transactional memory is hardware-based transactional memory.

14. The computer-readable storage medium of claim 9, wherein the trap event is generated in response to one of an invalid memory reference, a divide-by-zero error, a hardware event, and a user-generated interrupt.

15. The computer-readable storage medium of claim 9, wherein plurality of instructions included in the transaction represent an atomic sequence of steps that should either each be performed without interruption or the transaction aborted.

16. The computer-readable storage medium of claim 9, wherein the operation further comprises, prior to the execution of the thread at the first instruction of the transaction being resumed, passing an error code to the thread indicating a cause of the trap event.

17. A system, comprising:

a processor;

a transactional memory; and

a transactional memory manager configured to perform an operation for regaining memory consistency after a trap event via the transactional memory, the operation comprising;

initiating, by a first thread, a transaction, wherein the transaction includes a plurality of instructions,

recording a sequence of changes made to the transactional memory while executing the plurality of instructions,

detecting the occurrence of a trap event prior to completing the transaction,

rolling back the sequence of changes made to the transactional memory up to a first instruction of the transaction, based on the recorded sequence, and

resuming execution of the thread at the first instruction of the transaction.

18. The system of claim 17, wherein the operation further comprises, and prior to resuming execution of the thread at the first instruction of the transaction, invoking a trap-handler associated with the detected trap event.

19. The system of claim 17, wherein the operation further comprises:

determining whether the transaction has been initiated and rolled back, on the basis of a detected trap event, more than a specified a number of times; and

terminating the first thread if the number of interruptions has exceeded a predetermined threshold.

20. The system of claim 17, wherein the transactional memory is software-based transactional memory.

21. The system of claim 17, wherein the transactional memory is hardware-based transactional memory.

22. The system of claim 17, wherein the trap event is generated in response to one of an invalid memory reference, a divide-by-zero error, a hardware event, and a user-generated interrupt.

23. The system of claim 17, wherein plurality of instructions included in the transaction represent an atomic sequence of steps that should either each be performed without interruption or the transaction aborted.

24. The system of claim 17, wherein the operation further comprises, prior to the execution of the thread at the first instruction of the transaction being resumed, passing an error code to the thread indicating a cause of the trap event.