LRU Queue Read-Write Locks for Concurrent Remove and Add-to-Front

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

LRU queues in systems like operating system kernels face contention issues due to the use of individual locks, leading to blocked operations when performing concurrent removal and add-to-front operations.

Innovation Solution

Implementing read-write locks instead of spin locks for LRU queues allows concurrent execution of remove and add-to-front operations by locking nodes in shared or exclusive modes, enabling parallel execution without locking the same nodes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If individual locks are used to protect LRU queue operations, then data consistency is maintained, but operation concurrency is reduced causing blocked operations

Engineering Contradiction:
Improvedata consistencyVSAvoidoperation concurrency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the LRU queue into multiple independent segments or regions, each protected by its own lock. This allows different segments to be accessed concurrently by multiple operations, thereby improving concurrency while maintaining data consistency within each segment. The queue is divided such that remove operations and add-to-front operations can work on different segments simultaneously without conflicting.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies different locking strategies to different parts of the LRU queue. Specifically, it uses fine-grained locking where only the specific nodes or segments being accessed are locked, rather than locking the entire queue. This local quality approach allows other parts of the queue to be accessed concurrently, improving overall operation concurrency while maintaining consistency in the accessed regions.

Inventive Principle:
Principle #3Local quality

2Reliability

If remove operations lock nodes to ensure safe removal, then data integrity is maintained, but add-to-front operations are blocked when attempting to lock the same nodes

Engineering Contradiction:
Improvedata integrityVSAvoidoperation parallelism
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements dynamic locking where locks are acquired and released based on the specific needs of each operation at different times. Remove operations lock nodes only when actually removing them, while add-to-front operations lock nodes only when adding. This dynamic approach allows the same node to be accessed by different operations at different times without permanent blocking, enabling better parallelism while maintaining data integrity during critical operations.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent uses preliminary locking where nodes are locked in advance by one operation before another operation can access them. Specifically, when a remove operation locks a node for removal, add-to-front operations are prevented from adding to that same node until the remove operation completes and releases the lock. This preliminary action ensures data integrity while minimizing the duration of conflicts, allowing operations to proceed in parallel when not conflicting.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11442871B2Supporting concurrent remove operations and add-to-front operations on a Least Recently Used (LRU) queue
Publication Date: 2022.09.13 ORACLE INT CORP
  • US11442871B2 patent drawing
  • US11442871B2 patent drawing
  • US11442871B2 patent drawing

AI summary

A remove operation and an add-to-front operation may be currently performed with respect to nodes in an Least Recently Used (LRU) queue. A remove operation for a node may proceed if a lock can be obtained on the node to be removed and a predecessor node. During the remove operation, an add-to-front operation may proceed if a lock can be obtained on a dummy node that precedes the current front node of the LRU queue.