Runtime Synchronization Trace Analysis for Thread Contention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-threaded applications, shared resources often lead to deadlocks and performance bottlenecks due to contention among threads competing for synchronization primitives, where only one thread can use a resource at a time, causing others to wait and resulting in inefficient parallel execution.

Innovation Solution

The development of techniques to evaluate synchronization traces and provide a user interface for analyzing thread synchronization problems, identifying which software components and threads are blocked due to contention of synchronization primitives, allowing for detailed analysis of critical sections and shared resource contention at the method and software component level.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If multiple threads share resources using synchronization primitives, then resource consistency is maintained, but thread productivity decreases due to blocking and waiting

Engineering Contradiction:
Improveresource consistencyVSAvoidthread execution efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system collects synchronization trace data that records thread blocking events and provides feedback through a user interface showing contention patterns, blocked threads, and resource access sequences. This feedback mechanism enables developers to analyze and optimize their multi-threaded applications to reduce unnecessary blocking while maintaining resource consistency.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent introduces an intermediary analysis system consisting of a runtime system, synchronization trace collector, and user interface. This intermediary layer captures synchronization primitive operations, records thread blocking events, and presents the data in an analyzable format without interfering with the actual thread execution or resource access patterns.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If threads wait for shared resources to become free, then resource consistency is maintained, but execution time increases due to blocking

Engineering Contradiction:
Improveshared resource consistencyVSAvoidthread blocking time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system provides feedback by collecting synchronization trace data that records the timing and sequence of thread blocking events. The user interface displays this data to show which threads are blocking others, how long they are blocked, and which resources are most contended, enabling optimization to reduce blocking time while maintaining consistency.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The runtime system performs preliminary collection and recording of synchronization trace data in the background, capturing blocking events before they complete. This allows analysis of blocking patterns and identification of optimization opportunities without adding significant overhead to the actual thread execution time.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If synchronization primitives are used to control resource access, then resource consistency is maintained, but device complexity increases

Engineering Contradiction:
Improveresource access consistencyVSAvoidsynchronization mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary analysis layer comprising a runtime system, trace collector, and user interface that operates independently from the core synchronization primitives. This intermediary layer captures and analyzes synchronization events without modifying the underlying synchronization mechanism, thereby maintaining resource access consistency while providing complexity analysis capabilities.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system creates a copy of the synchronization trace data that records thread blocking events and resource access patterns. This copied data is then analyzed and presented through the user interface without affecting the actual synchronization primitive operations, allowing complex analysis while maintaining the simplicity and correctness of the original synchronization mechanisms.

Inventive Principle:
Principle #26Copying

4Reliability

If only one thread uses a shared resource at a time, then resource consistency is maintained, but parallel execution efficiency decreases

Engineering Contradiction:
Improveshared resource consistencyVSAvoidparallel execution efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system collects feedback data through synchronization traces that record which threads are blocking others and for how long. The user interface presents this data to enable identification of contention hotspots and optimization opportunities, allowing developers to restructure code to reduce blocking and improve parallel execution efficiency while maintaining resource consistency.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent replaces direct mechanical monitoring of thread blocking with a software-based trace collection and analysis system. The runtime system collects synchronization trace data and the user interface presents it in an analyzable format, substituting the need for complex real-time monitoring mechanisms with a post-mortem analysis approach that provides similar insights with less overhead.

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

Data Source

PatentUS9280444B2System and method for identifying contention of shared resources in a runtime system
Publication Date: 2016.03.08 SAP SE
  • US9280444B2 patent drawing
  • US9280444B2 patent drawing
  • US9280444B2 patent drawing

AI summary

A system and computer-implemented method for determining a runtime of a thread of an application. Synchronization events for a first thread of an application executing on the computer system are received, the synchronization events including at least a first synchronization event and a second synchronization event for the first thread. A first difference between a synchronization event timestamp of the first synchronization event and the synchronization event timestamp of the second synchronization event is calculated. A second difference between an accumulated timestamp of the first synchronization event and the accumulated timestamp of the second synchronization event is calculated. A runtime of the first thread of the application is calculated as a difference between the first difference and the second difference.