Transactional Memory Compiler with Runtime Fallback

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Concurrent software designs face challenges in ensuring atomicity of operations across threads, leading to difficulties in reasoning about thread interactions and potential deadlocks due to the use of locks, while traditional transactional memory systems often require specific implementations and may not guarantee all transactions.

Innovation Solution

A compiler is configured to generate code that supports multiple alternative transactional memory techniques, allowing programmers to write transactional code once and enabling runtime selection of the appropriate implementation, which can include hardware or software support, and fallbacks to ensure atomicity without explicit locking.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If locks are used to ensure atomicity of operations, then correctness of concurrent access is improved, but complexity of software design and potential for deadlock increases

Engineering Contradiction:

Improvecorrectness of concurrent accessVSAvoidcomplexity of software design

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent replaces the mechanical locking system with a transactional memory system that uses software-based atomic operations. Instead of using locks that require manual acquisition and release, the system uses transactional memory blocks that automatically ensure atomicity through hardware or software support, eliminating the need for complex locking protocols and reducing the risk of deadlock.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The patent introduces an intermediary layer (transactional memory interface) between the programmer and the underlying concurrency control mechanism. This interface allows programmers to specify atomic operations without directly implementing locking logic, automatically managing the complexity of concurrent access control while maintaining correctness.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If locks are used to prevent concurrent access, then atomicity is ensured, but productivity of other threads decreases due to waiting

Engineering Contradiction:

Improveatomicity of operationsVSAvoidproductivity of other threads

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent implements fine-grained transactional memory where only the specific data items involved in a transaction are protected, rather than using coarse-grained locks that protect entire data structures. This allows other threads to access unrelated data without waiting, improving overall system productivity while maintaining atomicity for the protected operations.

Inventive Principle:

Principle #16Partial or excessive action

Solution Approach 2:

The patent segments the concurrency control into independent transaction units, each operating on specific data items. This segmentation allows multiple transactions to proceed concurrently if they operate on different data, reducing thread waiting time while ensuring atomicity within each transaction boundary.

Inventive Principle:

Principle #1Segmentation

3Device complexity

If a single transactional memory implementation is used, then simplicity of system design is improved, but adaptability to different transaction requirements decreases

Engineering Contradiction:

Improvesimplicity of system designVSAvoidadaptability to different transaction requirements

Core Design Contradiction:

Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent designs a universal transactional memory interface that can work with multiple underlying implementation techniques (hardware transactional memory, software transactional memory, hybrid approaches). This single interface adapts to different requirements by selecting or combining implementation strategies, providing both simplicity for programmers and versatility for different transaction scenarios.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent implements a dynamic transactional memory system that can adapt its behavior based on runtime conditions. The system can switch between different implementation techniques (e.g., from hardware-supported to software-based) depending on the specific transaction requirements, system state, and performance needs, providing both simplicity and adaptability.

Inventive Principle:

Principle #15Dynamics

Data Source

PatentUS7921407B2System and method for supporting multiple alternative methods for executing transactions

Publication Date: 2011.04.05 ORACLE AMERICAN INC

AI summary

Transaction code written by the programmer may be translated, replaced or transformed into a code that is configured to implement transactions according to any of various techniques. A compiler may replace programmer written transaction code into code allowing multiple compatible transaction implementation techniques to be used in the same program, and at the same time. A programmer may write transaction code once using familiar coding styles, but the transaction to be effected according to one of a number of compatible alternative implementation techniques. The compiler may enable the implementation of multiple, alternative transactional memory schemes. The particular technique implemented for each transaction may not be decided until runtime. At runtime, any of the various implemented techniques may be used to effect the transaction and if a first technique fails or is inappropriate for a particular transaction, one or more other techniques may be attempted.