Weak Lock Mechanism for High Priority Thread Preemption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Low priority background threads in storage clusters, such as virtual large block redirection cleaners, often utilize the same resources and locks as high priority I/O processing threads, leading to increased latency for high priority I/O requests due to long lock holds, even during off-peak hours when they aim to utilize idle CPU cycles.
Innovation Solution
Implementing a 'weak lock' mechanism that allows high priority tasks to preempt locks acquired by low priority tasks, enabling the release of locks before transactions are completed, and providing mechanisms like Yield Lock and TryYieldLock to manage transactions without impacting data consistency or causing unacceptable waiting times for higher priority tasks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If low priority background threads acquire locks to perform transactions with data, then data consistency is maintained, but high priority I/O requests experience increased latency due to long lock holds
Solution Approach 1:
The lock mechanism is made dynamic by introducing priority-based preemption. Lock ownership is no longer static but can be transferred based on task priority and transaction state. The system dynamically evaluates whether a low-priority task's transaction can be safely aborted to allow a high-priority task to proceed, thereby adapting lock behavior to real-time system needs.
Solution Approach 2:
The lock object's behavior is changed by introducing a priority parameter and transaction state parameters. The lock mechanism now considers task priority levels and transaction completion states to determine whether to preempt the current lock holder. This parameter-based approach allows the system to differentiate between critical and non-critical lock holdings.
2Productivity
If low priority background threads hold locks for long durations to complete batch transactions, then processing efficiency is improved, but high priority I/O requests are delayed
Solution Approach 1:
Instead of requiring complete batch processing before releasing locks, the system allows partial completion. Low-priority tasks can be preempted mid-transaction if a high-priority task needs the lock. The aborted transaction can be restarted later, sacrificing some batch processing efficiency to ensure timely I/O response.
Solution Approach 2:
The system performs preliminary checks before allowing a task to hold a lock for extended periods. By evaluating task priority and transaction state early, the system can prevent long lock holdings by low-priority tasks when high-priority tasks are waiting, thereby proactively avoiding I/O delays.
3Loss of time
If locks are released before transaction completion to allow high priority tasks, then I/O latency is reduced, but data consistency may be compromised
Solution Approach 1:
The system implements feedback mechanisms to monitor transaction state and task priority continuously. Before preempting a low-priority task's lock, the system checks whether the transaction can be safely aborted without compromising data consistency. This feedback loop ensures that lock preemption decisions are made with full awareness of the current system state.
Solution Approach 2:
The lock object serves as an intermediary that mediates between conflicting task priorities and data consistency requirements. It maintains information about transaction state and priority levels, and uses this information to make intelligent decisions about lock preemption, balancing I/O latency reduction with data consistency preservation.
Data Source
AI summary
A method, computer program product, and computer system for identifying, by a computing device, an attribute of a lock object associated with data. It may be determined that the lock object is acquired by a first task performing a transaction with the data based upon, at least in part, the attribute of the lock object. The lock object may be acquired by a second task by releasing the lock object from the first task prior to the transaction with the data being completed, wherein the second task is a higher priority task than the first task.