Lock Management System Using Atomic Counter for Multiprocessor Thread Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multiprocessor systems, lock management methods face bottlenecks due to high frequency of non-conflicting lock requests, leading to mutex conflicts and reduced performance, especially when the number of threads acquiring locks cannot be expressed by a single word handled by an indivisible access command.
Innovation Solution
A lock management system that uses a lock status bit mask and counter sequence to manage lock acquisition and release processes, allowing lock acquisition without a mutex in non-conflicting modes, and employs indivisible access commands to handle lock status updates, enabling high-speed processing even when multiple lock modes are involved.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a mutex is used to manage lock acquisition in multiprocessor systems, then thread synchronization is ensured, but performance degrades due to mutex conflicts and bottlenecks under high frequency lock requests
Solution Approach 1:
The patent segments the lock management mechanism into two parts: a traditional mutex for conflict resolution and a counter variable for tracking lock status. This segmentation allows the system to use the counter for fast path operations (non-conflicting locks) while reserving the mutex only for actual conflicts, thereby reducing mutex contention and improving performance.
Solution Approach 2:
The patent introduces a counter variable as an intermediary between threads and the mutex. The counter acts as a mediator that handles the majority of lock acquisition and release operations without involving the mutex, thus reducing direct mutex conflicts. The mutex is only invoked when the counter indicates a potential conflict, making the intermediary essential for decoupling high-frequency operations from the synchronization bottleneck.
2Reliability
If the number of threads acquiring locks is tracked using multiple variables, then accurate lock status is maintained, but access complexity increases requiring mutex protection
Solution Approach 1:
The patent combines multiple lock status tracking variables into a single counter variable that uses atomic increment and decrement operations. This merging eliminates the need for separate variables for each thread's lock status, simplifying the data structure while maintaining accuracy through atomic operations that inherently provide synchronization without additional mutex complexity.
Solution Approach 2:
The patent replaces the mechanical mutex-based synchronization system with atomic counter operations. Instead of using mutex locks to protect access to multiple variables, the system uses atomic increment/decrement operations on a single counter, which are provided by the processor's hardware and eliminate the need for software-based mutex protection, thereby reducing complexity.
3Reliability
If atomic operations are used for lock management, then thread safety is improved, but processing speed decreases due to the overhead of atomic access commands
Solution Approach 1:
The patent applies local quality by using atomic operations only where necessary (during lock acquisition and release) while allowing non-atomic, faster operations for the bulk of the critical section execution. The atomic operations are localized to the minimal necessary points (counter increment/decrement), ensuring thread safety only where needed rather than throughout the entire processing path, thus minimizing the performance overhead.
Data Source
AI summary
Provided is a lock management system, a lock management method and a lock management program whereby lock acquisition and release processes can be carried out at high speed.A lock management system 1 having a multiprocessor includes: a lock acquisition process 310 for carrying out a lock acquisition process for a thread according to one or more lock modes, at least a portion of the lock modes being a shared lock that can be acquired by one or more threads; and lock status holding means 410 for managing the number of threads acquiring a lock, by first information which can express the number of threads by one word that can be handled by an indivisible access command of the multi-processor, and second information representing a whole range of the number of threads that can possibly acquire a lock in each lock mode.