Thread Lock Parameter Mechanism for Deadlock Prevention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In Single Instruction Multiple Thread (SIMT) systems, deadlocks occur due to threads competing for shared resources, leading to performance issues and system halts, as threads with higher program counters are prioritized over those needing exclusive access to shared resources.

Innovation Solution

Implementing a mechanism where the general program counter is set based on the thread with exclusive access to a shared resource, tracked using a lock parameter, and considering function call depth to ensure progress and prevent deadlocks, allowing threads with exclusive access to complete their operations before others can access the resource.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the general program counter is set to match the smallest program counter value among threads, then threads can converge and execute in lockstep, but threads with higher program counters (including those holding shared resources) cannot execute and deadlock occurs

Engineering Contradiction:
Improvethread convergenceVSAvoidthread execution progress
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent introduces a new parameter (lock parameter) to track shared resource access status and modifies the program counter selection criteria to consider this parameter. Instead of solely selecting based on smallest program counter value, the system now selects based on threads with lowest lock parameter values, allowing threads holding locks to be prioritized for execution and preventing deadlock while maintaining convergence through function call depth tracking.

Inventive Principle:
Principle #35Parameter changes

2Stability of the object's composition

If threads are prioritized based on lowest program counter values, then thread convergence is achieved, but threads holding shared resources are starved of execution and system halts

Engineering Contradiction:
Improvethread synchronizationVSAvoidsystem halt time
Core Design Contradiction:
Stability of the object's compositionVSLoss of time

Solution Approach 1:

The system implements feedback by continuously tracking lock parameters and function call depths, using this information to dynamically adjust thread selection. The feedback mechanism ensures that threads holding locks are identified and prioritized for execution, preventing the system from halting while maintaining overall thread synchronization through the function call depth counter.

Inventive Principle:
Principle #23Feedback

3Reliability

If function call depth tracking is implemented to prevent deadlock, then thread execution fairness improves, but system complexity increases

Engineering Contradiction:
Improvedeadlock preventionVSAvoidthread management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The function call depth counter serves multiple purposes: it tracks function call depth for proper thread selection ordering and simultaneously acts as a mechanism to prevent deadlock by ensuring threads with higher function call depths (likely holding resources) are prioritized. This multi-functionality reduces the need for separate deadlock detection and prevention mechanisms, thereby limiting the increase in system complexity.

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

Data Source

PatentEP3191955B1Shared resources in a data processing appartus for executing a plurality of threads
Publication Date: 2021.09.22 ARM LTD
  • EP3191955B1 patent drawingFigure 1
  • EP3191955B1 patent drawingFigure 2
  • EP3191955B1 patent drawingFigure 3

AI summary

A data processing apparatus (100) executes threads and includes a general program counter (PC) (120) identifying an instruction to be executed for at least a subset of the threads. Each thread has a thread PC (184). The subset of threads has at least one lock parameter (188, 500-504) for tracking exclusive access to shared resources. In response to a first instruction executed for a thread, the processor (160) modifies the at least one lock parameter (188), (500-504) to indicate that the thread has gained exclusive access to the shared resource. In response to a second instruction, the processor modifies the at least one lock parameter (188, 500-504) to indicate that the thread no longer has exclusive access. A selector (110) selects one of the subset of threads based on the at least one lock parameter (188, 500-504) and sets the general PC (120) to the thread PC (184) of the selected thread.