Compiler Shadow Copy Strategy for Software Transactional Memory Atomicity

Solution Overview

Problem

Software transactional memory systems face instability and performance issues due to accessing dead memory locations and unnecessary use of failure atomicity and concurrency atomicity techniques when dealing with stack allocated memory, which has a shorter lifetime than transactions.

Innovation Solution

A software transactional memory system interacts with a compiler to modify code segments at compile time, ensuring failure atomicity by saving copies in shadow local variables or optimizing by omitting logging and transactional memory operations based on whether stack locations are live or not, and ensuring both atomicities when unsure.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If failure atomicity techniques and concurrency atomicity techniques are used for stack allocated memory, then atomicity is ensured, but system performance deteriorates and unnecessary overhead is introduced

Engineering Contradiction:

ImproveatomicityVSAvoidsystem performance

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The compiler performs preliminary analysis at compile time to determine the lifetime of stack variables and identifies which variables are live on transaction entry. This preliminary classification allows the runtime system to apply atomicity techniques selectively rather than universally, avoiding unnecessary overhead for variables that don't require it.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

Different atomicity handling strategies are applied to different stack variables based on their specific characteristics. Variables determined to be live on transaction entry receive full atomicity protection through shadow copies and logging, while variables not live on entry use optimized paths without unnecessary atomicity overhead, creating local quality variations in the treatment of memory locations.

Inventive Principle:

Principle #3Local quality

2Reliability

If stack allocated memory is accessed with full atomicity checks, then reliability is improved, but device complexity increases due to additional logging and shadow variable management

Engineering Contradiction:

Improvetransaction atomicityVSAvoidcode complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The compiler performs preliminary analysis at compile time to determine the lifetime of stack variables and identifies which variables are live on transaction entry. This preliminary classification allows the runtime system to apply atomicity techniques selectively rather than universally, avoiding unnecessary overhead for variables that don't require it.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

Different atomicity handling strategies are applied to different stack variables based on their specific characteristics. Variables determined to be live on transaction entry receive full atomicity protection through shadow copies and logging, while variables not live on entry use optimized paths without unnecessary atomicity overhead, creating local quality variations in the treatment of memory locations.

Inventive Principle:

Principle #3Local quality

3Reliability

If shadow copies are created for all stack variables, then failure atomicity is ensured, but memory usage increases and system resources are consumed

Engineering Contradiction:

Improvefailure atomicityVSAvoidmemory usage

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

Shadow copies are created selectively only for stack variables that are determined to be live on transaction entry, rather than for all stack variables. This localized application of shadow copying reduces memory overhead while maintaining failure atomicity for the critical variables that require it.

Inventive Principle:

Principle #3Local quality

Solution Approach 2:

Instead of applying shadow copying to all stack variables (excessive action), the system applies it only to the subset of variables that are live on transaction entry (partial action), achieving sufficient failure atomicity with reduced memory consumption.

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentUS7895582B2Facilitating stack read and write operations in a software transactional memory system

Publication Date: 2011.02.22 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

Various technologies and techniques facilitate stack read and write operations in a software transactional memory system. If the compiler determines that an address for a variable in a code segment is a stack location, the stack location is live on entry, and the address of the variable has not been taken and passed to another thread, the code is changed to ensure failure atomicity. One example includes modifying the code so a shadow copy is saved for local variables that are live on entry. If the same prior criteria are true except the stack location is not live on entry, the code is optimized by ensuring code for logging and software transactional memory operations are not included. If the compiler does not know the address is the stack location or that the address is not passed to another thread, the code is changed to ensure failure and concurrency atomicity.