Lock Server Write Lock Queue for Cluster Starvation Prevention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In a cluster environment, the lock server fails to recognize clients waiting for write locks when a client becomes faulty, leading to lock starvation and inefficient resource allocation.

Innovation Solution

Implementing a lock management method that uses a write lock request queue and allocation identifiers to track clients' lock states, allowing the lock server to determine whether a client has obtained or is waiting for a write lock, and automatically releasing locks held by faulty clients to prevent resource bottlenecks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If the lock server uses a simple lock allocation mechanism without tracking waiting clients, then the device complexity is reduced, but the reliability deteriorates when clients become faulty causing lock starvation

Engineering Contradiction:
Improvelock management mechanismVSAvoidlock allocation reliability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The lock server pre-establishes a write lock request queue in memory before any lock conflicts occur. This queue is ready to store client identifiers and track waiting status proactively, so when a client becomes faulty, the system can immediately identify and handle waiting clients without complex runtime analysis

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The lock server implements a feedback mechanism where client identifiers are continuously recorded in the write lock request queue whenever they request or wait for write locks. This creates a real-time tracking system that provides feedback about lock state, enabling the server to reliably detect and handle faulty clients while maintaining relatively simple architecture

Inventive Principle:
Principle #23Feedback

2Reliability

If the lock server tracks all waiting clients in memory, then the reliability improves by preventing lock starvation, but the use of energy increases due to continuous memory maintenance

Engineering Contradiction:
Improvelock allocation reliabilityVSAvoidmemory maintenance energy
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The write lock request queue is designed to automatically manage client identifier storage and retrieval without requiring active intervention or continuous processing. The queue structure itself maintains the tracking information passively, reducing the need for energy-consuming active management while ensuring reliable detection of waiting clients

Inventive Principle:
Principle #25Self-service

3Productivity

If the lock server implements comprehensive client state tracking, then the productivity improves by preventing resource bottlenecks, but the device complexity increases

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoidstate tracking mechanism
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system pre-configures the write lock request queue structure in memory before operation, establishing the tracking framework in advance. This eliminates the need for complex runtime state management logic, as the queue structure automatically handles client identifier storage and retrieval, thereby improving productivity without proportionally increasing device complexity

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS10609150B2Lock management method in cluster, lock server, and client
Publication Date: 2020.03.31 HUAWEI TECH CO LTD
  • US10609150B2 patent drawing
  • US10609150B2 patent drawing
  • US10609150B2 patent drawing

AI summary

A lock management solution in a cluster, where the cluster includes a client and a lock server, the lock server includes an interface card and a memory, the memory stores a read lock request queue recording an identifier of a client waiting for a read lock or obtaining the read lock, the memory further stores a write lock request queue recording an identifier of a client waiting for a write lock or obtains the write lock, and the memory further includes a read lock allocation count and a write lock allocation identifier, where the read lock allocation count records an allocated read lock, and the write lock allocation identifier indicates whether the write lock has been allocated.