Transactional Memory Abort Control for Multi-Core Contention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The increasing number of cores and logical processors in integrated circuits leads to challenges in synchronizing shared data among software threads, resulting in false contention, serialization, and complexity in lock contention, deadlock avoidance, which existing synchronization techniques like locks and transactional memory have not fully addressed, especially in terms of performance and scalability.

Innovation Solution

The implementation of lock elision and transactional memory mechanisms in processors, which allow for speculative execution of critical sections without locks, using hardware and software collaboration to monitor and commit transactions, reducing contention and improving throughput by enabling concurrent execution of threads.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If locks are used to synchronize shared data among multiple software threads, then data integrity is ensured, but execution serialization and false contention occur, reducing throughput

Engineering Contradiction:
Improvedata integrityVSAvoidthroughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent extracts the locking mechanism from the critical section execution, allowing threads to execute speculatively without acquiring locks. The lock elision logic monitors for conflicts and aborts speculation only when necessary, thereby removing the serialization effect of locks while preserving data integrity through conflict detection and abort mechanisms.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent performs preliminary conflict detection and resolution before commits are made visible. By monitoring memory accesses and detecting conflicts in advance, the system can abort speculative executions before they cause data integrity issues, allowing most threads to proceed without lock overhead.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If the number of cores and logical processors is increased to execute more software threads concurrently, then processing capacity is improved, but lock contention complexity and deadlock avoidance burden increase

Engineering Contradiction:
Improveprocessing capacityVSAvoidsynchronization complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements self-service through hardware-based monitoring and conflict detection that automatically manages synchronization without programmer intervention. The system autonomously detects conflicts, aborts speculative executions, and ensures data integrity, eliminating the need for programmers to manually manage lock contention and deadlock avoidance in multi-core systems.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces the mechanical lock-based synchronization system with a hardware-monitored speculative execution system. Instead of using software locks that require manual management, the system uses hardware to monitor memory accesses, detect conflicts, and manage thread coordination automatically, reducing synchronization complexity.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Productivity

If transactional memory is implemented to execute groups of micro-operations atomically, then lock contention is reduced, but hardware complexity and abort handling overhead increase

Engineering Contradiction:
Improveconcurrent execution capabilityVSAvoidhardware complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent merges lock elision with existing speculative execution and branch prediction hardware. By integrating the monitoring and conflict detection logic into the existing instruction fetch, decode, and execute pipeline, the system achieves transactional memory functionality without adding separate complex hardware structures, thereby reducing overall hardware complexity.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent creates a universal synchronization mechanism that handles both traditional locked critical sections and transactional memory operations through a single lock elision framework. The same hardware monitoring and conflict detection logic serves multiple purposes: detecting lock conflicts, monitoring transactional memory accesses, and managing abort conditions, thereby reducing the need for separate specialized hardware.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Productivity

If speculative execution is used to eliminate locks from critical sections, then throughput is improved, but false aborts may occur, reducing reliability

Engineering Contradiction:
ImprovethroughputVSAvoidexecution correctness
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements feedback through continuous monitoring of memory accesses during speculative execution. The hardware monitors read and write sets, detects conflicts with other threads, and provides feedback that triggers aborts only when actual conflicts are detected. This feedback mechanism ensures that speculative execution maintains reliability by aborting only when necessary while preserving throughput for conflict-free executions.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10409612B2Apparatus and method for transactional memory and lock elision including an abort instruction to abort speculative execution
Publication Date: 2019.09.10 INTEL CORP
  • US10409612B2 patent drawing
  • US10409612B2 patent drawing
  • US10409612B2 patent drawing

AI summary

An apparatus and method is described herein for providing robust speculative code section abort control mechanisms. Hardware is able to track speculative code region abort events, conditions, and/or scenarios, such as an explicit abort instruction, a data conflict, a speculative timer expiration, a disallowed instruction attribute or type, etc. And hardware, firmware, software, or a combination thereof makes an abort determination based on the tracked abort events. As an example, hardware may make an initial abort determination based on one or more predefined events or choose to pass the event information up to a firmware or software handler to make such an abort determination. Upon determining an abort of a speculative code region is to be performed, hardware, firmware, software, or a combination thereof performs the abort, which may include following a fallback path specified by hardware or software. And to enable testing of such a fallback path, in one implementation, hardware provides software a mechanism to always abort speculative code regions.