Transactional processing

• US 9,766,925 B2
• Filed: 03/08/2013
• Issued: 09/19/2017
• Est. Priority Date: 06/15/2012
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Greiner, Dan F., Jacobi, Christian, Slegel, Timothy J.
• Primary Examiner(s): Pham, Tuan A
• Application Number:
  US13/789,808
• Publication Number:
  US 20130339961A1
• Time in Patent Office: 1,656 Days
• Field of Search: None
• CPC Class Codes: G06F 9/3004 to perform operations on memory
• CPC Class Codes: G06F 9/30087 Synchronisation or serialisation instructions
• CPC Class Codes: G06F 9/3834 Maintaining memory consistency
• CPC Class Codes: G06F 9/467 Transactional memory G06F9/528 takes precedence

Abstract

A transaction is initiated via a transaction begin instruction. During execution of the transaction, the transaction may abort. If the transaction aborts, a determination is made as to the type of transaction. Based on the transaction being a first type of transaction, resuming execution at the transaction begin instruction, and based on the transaction being a second type, resuming execution at an instruction following the transaction begin instruction. Regardless of transaction type, resuming execution includes restoring one or more registers specified in the transaction begin instruction and discarding transactional stores. For one type of transaction, the nonconstrained transaction, the resuming includes storing information in a transaction diagnostic block.

Claims

1. A method of controlling execution of a transaction in a computing environment, the method comprising:

executing a transaction begin instruction, the transaction begin instruction to begin any one of a first type of transaction or a second type of transaction, the transaction comprising a plurality of instructions to be executed, and the transaction begin instruction explicitly indicating by a field of the transaction begin instruction the first type of transaction or the second type of transaction being initiated;

based on the transaction being the second type of transaction, the executing setting a condition code to a first value;

initiating, by a processor, execution of the transaction in a transaction mode via the transaction begin instruction;

based on being in the transaction mode, effectively delaying committing transactional stores to main memory until completion of a selected transaction;

based on the transaction aborting, determining the type of transaction initiated, the type of transaction being the first type of transaction or the second type of transaction, and the determining being based on the field of the transaction begin instruction;

based on the transaction aborting and the transaction being the first type of transaction, resuming execution at the transaction begin instruction; and

based on the transaction aborting and the transaction being the second type of transaction, setting the condition code to a second value, wherein the second value indicates a next sequential instruction following the transaction begin instruction is receiving control from the abort, and resuming execution at the next sequential instruction directly following the transaction begin instruction in program order.

2. The method of claim 1, wherein the first type of transaction is a constrained transaction having one or more restrictions associated therewith, and the transaction begin instruction is a transaction begin constrained instruction, and wherein the second type of transaction is a nonconstrained transaction.

3. The method of claim 1, wherein the transaction is the second type of transaction, the second type being a nonconstrained transaction, and wherein the resuming execution comprises:

checking by the next sequential instruction following the transaction begin instruction a condition code of the transaction to determine whether the instruction is receiving control from an abort; and

based on the instruction receiving control from the abort, performing processing to handle the abort.

4. The method of claim 3, wherein the performing processing comprises taking action based on the condition code, wherein based on a condition code of one value, the action includes re-executing the transaction, and based on a condition code of another value, the action includes branching to a fall-back path.

5. The method of claim 1, wherein the transaction is the second type of transaction, the second type being a nonconstrained transaction, and wherein the method further comprises based on the transaction aborting, storing diagnostic information in a transaction diagnostic block specified by the transaction begin instruction.

6. The method of claim 1, further comprising based on the aborting, restoring one or more registers designated in the transaction begin instruction and discarding transactional stores.

7. The method of claim 1, further comprising:

determining that the transaction has aborted;

based on determining that the transaction has aborted, determining whether the abort was due to an interception or interruption; and

based on the abort being due to other than an interception or interruption, performing the resuming execution at the transaction begin instruction or resuming execution at the next sequential instruction depending on the transaction being the first type or the second type, respectively.

8. The method of claim 1, wherein the transaction is part of a nest of transactions, and wherein the method further comprises executing by the processor an extract nesting depth instruction to obtain an indication of a nesting depth of the nest of transactions.

9. The method of claim 8, wherein the transaction is an outermost transaction of the nest of transactions.

10. The method of claim 1, wherein the first type of transaction is a constrained transaction having one or more restrictions associated therewith, the one or more restrictions including:

only a subset of general instructions is available for inclusion in the constrained transaction, the constrained transaction is limited to a predetermined number of instructions to be executed in the constrained transaction, the constrained transaction is limited to a predetermined number of storage operands to be accessed in the constrained transaction, or the constrained transaction is limited to a single nesting level, and wherein the second type of transaction is a nonconstrained transaction, the nonconstrained transaction not limited by the one or more restrictions associated with the constrained transaction.