Decentralized Lock Manager for Multi-Core Architectures
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-core computer architectures, managing locks becomes increasingly complex and communication-intensive as the number of processors increases, leading to communication delays and resource burdens due to the need for centralized lock management and high network traffic.
Innovation Solution
A decentralized lock management system where each processing device has a lock manager that broadcasts messages over an interconnection network to manage lock ownership and requests, reducing the number of messages and network traffic by using a distributed waiting list and finite state machine logic to handle lock creation, transfer, and ownership.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If centralized lock management is used in multi-core architectures, then lock ownership can be tracked, but communication burden and network traffic increase significantly
Solution Approach 1:
The patent divides the centralized lock management system into distributed lock managers, one at each processing device. Each lock manager independently tracks lock ownership for its local processor, segmenting the monolithic communication burden into smaller, localized units. This segmentation reduces overall network traffic while maintaining reliable lock tracking through distributed coordination.
Solution Approach 2:
The patent implements local lock management where each processing device has its own lock manager that handles lock ownership locally. This local quality approach minimizes remote communications by resolving lock requests at the local level whenever possible, reducing the communication burden while maintaining accurate lock tracking through selective broadcasting only when necessary.
2Productivity
If the number of processors increases, then parallel task execution increases, but the number of locks and management complexity increases
Solution Approach 1:
The patent segments the lock management system into independent lock managers at each processing device, allowing parallel task execution to scale with processor count without proportionally increasing central management complexity. Each lock manager operates semi-autonomously, managing locks locally while participating in distributed coordination only when needed.
Solution Approach 2:
The patent enables each processing device to self-manage its lock ownership through local lock managers that automatically track and communicate lock state changes. This self-service approach reduces the coordination overhead that would otherwise scale linearly with processor count, as each node independently manages its own lock state while maintaining system-wide consistency through selective broadcasting.
3Stability of the object's composition
If lock ownership is broadcast to all lock managers, then lock state consistency is maintained, but network congestion increases
Solution Approach 1:
The patent implements selective broadcasting where lock state changes are communicated only to relevant lock managers rather than universally to all. This local quality approach maintains lock state consistency by targeting communications only to nodes that need to know about the state change, reducing unnecessary network traffic while preserving system-wide consistency.
Solution Approach 2:
The patent inverts the traditional broadcasting model by having lock managers pull state information on demand or receive targeted notifications only when relevant, rather than pushing updates to all nodes continuously. This inversion reduces network traffic by eliminating redundant communications to nodes that don't need the information, while maintaining consistency through selective information distribution.
Data Source
AI summary
A multi-core architecture including: a plurality of processing devices, each processing device including a single processor or a cluster of processors; and a lock manager associated with each processing device, each lock manager being configured to: store a first data value indicating of whether or not it currently owns a first lock, the first lock authorizing access to a resource; and permit an owner of the first lock to be determined by one or more lock managers by broadcasting, over an interconnection network to each of the other lock managers, at least one message.