Transactional Execution Branch Indications for Abort Diagnosis

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multiprocessor environments, updating multiple storage locations simultaneously by multiple CPUs is challenging due to the need for serialization, which can lead to coarse-grained locking issues and potential deadlocks, and managing exception conditions in transactional processing is costly and complex.

Innovation Solution

A transactional execution facility that allows for block-concurrent storage accesses within transactions, which can be committed or aborted atomically, and provides diagnostic information on aborts, enabling finer-grained serialization and improved error handling through nested transactions and constrained execution modes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If lock words are used for interlocked update of multiple storage locations, then atomicity is improved, but serialization granularity becomes too coarse leading to reduced productivity

Engineering Contradiction:
ImproveatomicityVSAvoidserialization overhead
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the serialization mechanism by introducing multiple lock words (first lock word and second lock word) corresponding to different storage locations. This allows fine-grained locking where only the specific lock word associated with the contested storage location is involved in the interlock, rather than serializing the entire data structure. The segmentation enables concurrent access to different portions of data while maintaining atomicity for each specific update operation.

Inventive Principle:
Principle #1Segmentation

2Productivity

If fine-grained serialization is implemented through data structure hierarchy, then productivity is improved, but device complexity increases due to potential deadlock situations and recovery issues

Engineering Contradiction:
Improveserialization efficiencyVSAvoidlock management complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements self-service through automatic conflict detection and transaction rollback mechanisms. When a fetch conflict or store conflict is detected during transactional execution, the system automatically aborts the transaction and restores storage locations to their pre-transaction state without requiring complex manual deadlock detection or recovery procedures. This eliminates the need for sophisticated lock hierarchy management and recovery protocols.

Inventive Principle:
Principle #25Self-service

3Device complexity

If transactional execution is implemented without diagnostic information, then device complexity is reduced, but loss of information increases making error handling costly and complicated

Engineering Contradiction:
Improveerror handling complexityVSAvoidabort diagnostic information
Core Design Contradiction:
Device complexityVSLoss of information

Solution Approach 1:

The patent introduces an intermediary mechanism in the form of a transaction diagnostic block that captures and stores abort diagnostic information. This block serves as a mediator between the transactional execution facility and the program, providing structured information about abort causes, conflict locations, and transaction state without adding significant complexity to the core execution mechanism. The diagnostic block enables comprehensive error handling and debugging capabilities.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2862081B1Transactional execution branch indications
Publication Date: 2018.10.17 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • EP2862081B1 patent drawingFigure 1
  • EP2862081B1 patent drawingFigure 2A~3B
  • EP2862081B1 patent drawingFigure 4~5

AI summary

Transactional execution branch indications are placed into one or more transaction diagnostic blocks when a transaction is aborted. Each branch indication specifies whether a branch was taken, as a result of executing a branch instruction within the transaction. As the transaction executes and a branch instruction is encountered, a branch indication is set in a vector indicating whether the branch was taken. Then, if the transaction aborts, the indicators are stored in one or more transaction diagnostic blocks providing a branch history usable in diagnosing the failure.