Transactional Memory Function Versioning via Stub Pointers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software transactional memory systems require programmers to create and manage two versions of functions, one for transactional and one for non-transactional contexts, which can be complex and error-prone, especially for virtual functions and function pointers, due to the need for context-dependent determination of the appropriate function version at runtime.
Innovation Solution
A transactional memory system generates and manages two versions of each function marked as transaction-safe: a normal version and a transactional version, using stub pointers to direct calls based on execution context, with the normal version pointing to either the transactional version or a runtime error routine, simplifying the process by automating the creation and selection of function versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If programmers manually create and manage two versions of functions for transactional and non-transactional contexts, then the system can provide transactional memory functionality, but the complexity and error-proneness of the system increases
Solution Approach 1:
The compiler automatically generates both transactional and non-transactional versions of functions based on decorators in the source code, eliminating the need for manual version creation. The system self-manages the function versioning process by automatically determining which version to call based on execution context, thereby reducing complexity while maintaining reliability
Solution Approach 2:
The compiler performs preliminary action by pre-generating both versions of functions during the compilation process. Stub pointers are pre-configured to point to the appropriate function versions, and the compiler automatically handles the setup of transactional and non-transactional variants before the program executes, eliminating runtime complexity
2Adaptability or versatility
If the system determines function version selection at runtime for virtual functions and function pointers, then context-dependent function calls are enabled, but the complexity of managing transactional and non-transactional versions increases
Solution Approach 1:
Stub pointers serve as intermediaries between the function call interface and the actual function implementations. These stub pointers are configured during compilation to automatically resolve to the correct function version (transactional or non-transactional) based on the execution context, enabling adaptability without runtime complexity
Solution Approach 2:
The compiler performs preliminary configuration of stub pointers and function version mappings during the compilation process. This preliminary action eliminates the need for runtime determination of function versions, as the correct version is already designated through stub pointers and compiler-generated code, thereby reducing complexity while maintaining context-dependent adaptability
Data Source
AI summary
Various technologies and techniques are disclosed for creating and/or locating transactional code blocks in a transactional memory system. A user such as a software developer can decorate a particular function with an identifier to indicate that the particular function is transaction-safe. A normal version and a transactional version are then created for each function of a software application that is marked as transaction-safe. A normal version is created for each function that is not marked as transaction-safe. For the normal version of each function that is marked as transaction-safe, a stub pointer in the normal version is pointed to the transactional version. The proper version of the function is then called depending on the execution context.