Reciprocating Lock Queues for Low-Latency Thread Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing lock operations in modern computer systems face inefficiencies in synchronizing multiple threads for access to shared data structures, particularly under contention and uncontended conditions, leading to high latency and potential starvation.
Innovation Solution
The implementation of reciprocating locks using arrival and wait queues with constant-time allocation and release phases, combined with thread-local spinning and bounded memory usage, ensures efficient synchronization with strong anti-starvation properties and high throughput.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional lock operations are used for thread synchronization, then threads can access shared data structures, but latency increases and starvation may occur under contention
Solution Approach 1:
The lock operation is segmented into two distinct phases: an arrival phase where threads push allocation requests onto an arrival queue in constant time, and a release phase where the lock holder pops requests from the wait queue. This segmentation allows threads to quickly register their intent without blocking, separating the expensive waiting operation from the acquisition operation.
Solution Approach 2:
Two queues (arrival queue and wait queue) are introduced as intermediary data structures between the lock holder and waiting threads. These queues mediate the transfer of control, allowing the lock holder to efficiently manage multiple waiting threads without direct contention, thereby reducing latency and preventing starvation.
2Reliability
If threads wait for lock allocation under contention, then fairness is maintained, but throughput decreases
Solution Approach 1:
The waiting threads are segmented into an arrival queue (for new requests) and a wait queue (for active waiting). This segmentation allows the system to maintain fairness by processing threads in order while improving throughput by allowing the lock holder to efficiently manage multiple waiters without repeated contention overhead.
Solution Approach 2:
Threads perform preliminary action by pushing their allocation requests onto the arrival queue before actually waiting. This preliminary registration allows the system to prepare the wait queue in advance, enabling the lock holder to efficiently transfer control to the next waiting thread without repeated synchronization operations, thereby maintaining fairness while improving throughput.
3Device complexity
If traditional lock implementations are used, then simplicity is maintained, but memory usage increases under high contention
Solution Approach 1:
The patent extracts the memory-intensive waiting structure from the lock implementation itself and places it in thread-local storage. Each thread maintains its own waiting element rather than requiring a large shared waiting structure, thereby reducing overall memory usage while maintaining simplicity in the lock's core logic.
Solution Approach 2:
Threads serve themselves by allocating and managing their own waiting elements in thread-local storage. This self-service approach eliminates the need for complex shared data structures to track all waiting threads, reducing memory usage while keeping the lock implementation simple and efficient.
Data Source
AI summary
One or more processors and memory may implement threads that perform allocations of a lock operation to synchronize access to a resource. Associated with the lock are two queues, an arrival queue and a wait queue. To allocate a lock, a thread pushes an allocation request onto the head of the arrival queue. When another thread holding the lock completes access to the resource, that thread transfers control according to a most recently arrived request in the wait queue. If no requests exist in the wait queue, the other thread transfers all requests, in arrival order, from the arrival queue to the wait queue, then transfers control according to a most recently arrived request in the wait queue. Requests segments transferred from the arrival queue to the wait queue are processed in first-in-first-out order while individual requests in a segment are processed in last-in-first-out order.