Dynamic management of a transaction retry indication

Patent metadata

Field	Value
Publication number	US-9400657-B2
Application number	US-201313868392-A
Country	US
Kind code	B2
Filing date	Apr 23, 2013
Priority date	Jun 15, 2012
Publication date	Jul 26, 2016
Grant date	Jul 26, 2016

Abstract

Embodiments relate to dynamic management of a transaction retry indication. One aspect is a system that includes a transactional facility configured to support transactions that effectively delay committing stores to memory or results to an architectural state until transaction completion, and a processor configured to identify a transaction abort reason associated with an aborted transaction of an initiating program. Transaction success and transaction abort history are tracked. Based on determining by the processor that the transaction abort reason was caused by the initiating program, a retry indication is assigned based on a static mapping of the transaction abort reason. Based on determining by the processor that the transaction abort reason was not caused by the initiating program, the retry indication is assigned based on a retry process using the transaction abort reason, the transaction abort history, and a current processor configuration.

First claim

What is claimed is:

1. A system for dynamic management of a transaction retry indication, the system comprising:
a transactional facility configured to support transactions that effectively delay committing stores to memory or results to an architectural state until transaction completion; and
a processor configured to perform a method comprising:
identifying, by the processor, a transaction abort reason associated with an aborted transaction of an initiating program;
tracking transaction success and a transaction abort history;
maintaining the transaction abort history per thread across multiple threads;
based on determining, by the processor, that the transaction abort reason was caused by the initiating program, assigning a retry indication based on a static mapping of the transaction abort reason, the retry indication providing an indication to the initiating program on whether to retry the aborted transaction;
based on determining, by the processor, that the transaction abort reason was not caused by the initiating program, assigning the retry indication based on a retry process using the transaction abort reason, the transaction abort history, and a current processor configuration, wherein the retry process is based on heuristic indicators for abort retry success based on a likelihood of success on a retry associated with the transaction abort reason, the transaction history, and the current processor configuration, and the retry process accounts for sharing of resources between the threads and indicates that the aborted transaction should be retried based on determining that one of: resource reallocation and arbitration between the threads has a likelihood of transaction success; and
validating an accuracy of the transaction abort history for each of the threads by setting a previous transaction successful flag when a transaction completes without abort processing and clearing the transaction abort history based on detecting that the previous transaction successful flag is set when abort processing begins.

2. The system of claim 1 , wherein the heuristic indicators are configurable to enable performance tuning of the system.

3. The system of claim 1 , wherein the retry process utilizes one or more of:
a number of times that the aborted transaction has aborted;
an indication of recent transaction success;
counters for categories of abort reasons;
abort collision addresses; and
a counter indicating a number of instructions executed within the aborted transaction before it is aborted.

4. The system of claim 1 , wherein the retry process is based on engineering modes to enable hardware verification, and specific abort reasons are statically assigned to specific retry indications.

5. A method for dynamic management of a transaction retry indication in a transactional facility, the method comprising:
identifying, by a processor, a transaction abort reason associated with an aborted transaction of an initiating program;
tracking transaction success and a transaction abort history;
maintaining the transaction abort history per thread across multiple threads;
based on determining, by the processor, that the transaction abort reason was caused by the initiating program, assigning a retry indication based on a static mapping of the transaction abort reason, the retry indication providing an indication to the initiating program on whether to retry the aborted transaction;
based on determining, by the processor, that the transaction abort reason was not caused by the initiating program, assigning the retry indication based on a retry process using the transaction abort reason, the transaction abort history, and a current processor configuration, wherein the retry process is based on heuristic indicators for abort retry success based on a likelihood of success on a retry associated with the transaction abort reason, the transaction history, and the current processor configuration, and the retry process accounts for sharing of resources between the threads and indicates that the aborted transaction should be retried based on determining that one of: resource reallocation and arbitration between the threads has a likelihood of transaction success; and
validating an accuracy of the transaction abort history for each of the threads by setting a previous transaction successful flag when a transaction completes without abort processing and clearing the transaction abort history based on detecting that the previous transaction successful flag is set when abort processing begins.

6. The method of claim 5 , wherein the heuristic indicators are configurable to enable system performance tuning.

7. The method of claim 5 , wherein the retry process utilizes one or more of:
a number of times that the aborted transaction has aborted;
an indication of recent transaction success;
counters for categories of abort reasons;
abort collision addresses; and
a counter indicating a number of instructions executed within the aborted transaction before it is aborted.

8. The method of claim 5 , wherein the retry process is based on engineering modes to enable hardware verification, and specific abort reasons are statically assigned to specific retry indications.

9. A computer program product for dynamic management of a transaction retry indication in a transactional facility, the computer program product comprising:
a non-transitory storage medium readable by a processing circuit of a processor and storing instructions for execution by the processing circuit for performing a method comprising:
identifying, by the processor, a transaction abort reason associated with an aborted transaction of an initiating program;
tracking transaction success and a transaction abort history;
maintaining the transaction abort history per thread across multiple threads;
based on determining, by the processor, that the transaction abort reason was caused by the initiating program, assigning a retry indication based on a static mapping of the transaction abort reason, the retry indication providing an indication to the initiating program on whether to retry the aborted transaction;
based on determining, by the processor, that the transaction abort reason was not caused by the initiating program, assigning the retry indication based on a retry process using the transaction abort reason, the transaction abort history, and a current processor configuration, wherein the retry process is based on heuristic indicators for abort retry success based on a likelihood of success on a retry associated with the transaction abort reason, the transaction history, and the current processor configuration, and the retry process accounts for sharing of resources between the threads and indicates that the aborted transaction should be retried based on determining that one of: resource reallocation and arbitration between the threads has a likelihood of transaction success; and
validating an accuracy of the transaction abort history for each of the threads by setting a previous transaction successful flag when a transaction completes without abort processing and clearing the transaction abort history based on detecting that the previous transaction successful flag is set when abort processing begins.

10. The computer program product of claim 9 , wherein the heuristic indicators are configurable to enable system performance tuning.

11. The computer program product of claim 9 , wherein the retry process utilizes one or more of:
a number of times that the aborted transaction has aborted;
an indication of recent transaction success;
counters for categories of abort reasons;
abort collision addresses; and
a counter indicating a number

Assignees

• IBM

Inventors

• Busaba Fadi Y
• Thompto Brian W

Classifications

• G06F9/30145

  Instruction analysis, e.g. decoding, instruction word fields · CPC title

• G06F9/44 Primary

  Arrangements for executing specific programs · CPC title

• G06F9/50

  Allocation of resources, e.g. of the central processing unit [CPU] · CPC title

• G06F9/30076

  to perform miscellaneous control operations, e.g. NOP · CPC title

• G06F9/5011 Primary

  the resources being hardware resources other than CPUs, Servers and Terminals · CPC title