Pathname-Based Shared Data Locking via In-Memory Store
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing locking systems for shared data in computer systems face challenges in managing locks across multiple processes, particularly in maintaining lock exclusivity and efficiency, especially when dealing with shared memory or files, which often result in file management overhead and require updates when memory locations change.
Innovation Solution
A method and apparatus for locking shared data that involves a lock store to manage lock requests, where a pathname is stored upon initial lock acquisition and subsequent requests for corresponding pathnames are denied, allowing for directory-level locking and automatic lock release in case of process termination, with the lock managing program operating within the operating system kernel or as an API.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If shared memory or files are used to store locks, then lock management can be implemented across multiple processes, but file management overhead increases and updates are required when memory locations change
Solution Approach 1:
The patent introduces a lock store as an intermediary data structure that stores pathnames instead of using traditional file-based locking mechanisms. This intermediary layer sits between the locking system and the actual data files, eliminating the need for file management operations while still enabling cross-process lock coordination through shared memory access to the lock store.
Solution Approach 2:
The patent replaces the mechanical file-based locking system with a software-based in-memory locking mechanism. Instead of creating, opening, and managing physical lock files, the system uses in-memory data structures (lock store) to track locked pathnames, substituting file I/O operations with faster memory access while maintaining the same locking functionality.
2Reliability
If each process must be updated when shared memory location changes, then lock accuracy is maintained, but system complexity and update overhead increase
Solution Approach 1:
The patent uses pathname strings as copies or identifiers of the actual data locations rather than storing or transmitting the actual memory addresses. When data locations change, only the pathname mappings need to be updated in the filesystem, not the locking mechanism itself. The lock store stores these pathname copies, which remain valid even if the underlying memory locations change.
Solution Approach 2:
The pathname-based locking system serves multiple functions: it identifies data locations, provides a stable reference that doesn't change when memory locations change, and enables cross-process communication about locked resources. This universal pathname reference system eliminates the need for separate update mechanisms while maintaining lock accuracy.
3Reliability
If directory-level locking is implemented, then broader data protection is achieved, but lock granularity increases
Solution Approach 1:
The patent segments the locking namespace into hierarchical levels corresponding to directory structures. Each pathname in the lock store represents a specific level of segmentation, allowing processes to lock individual files or entire directories depending on their needs. This segmentation enables fine-grained control where processes can choose the appropriate level of locking granularity rather than being forced into a single level.
Data Source
AI summary
Methods and apparatus are disclosed in which locks for shared data are acquired by specifying a pathname for the shared data. One embodiment, among others, includes a method for locking shared data. The method includes the steps of receiving a first request to acquire a lock for a first pathname, storing the first pathname in a lock store, searching the lock store for a corresponding pathname in response to a further request to acquire a lock for a second pathname, and if the second pathname corresponds to the first pathname in the lock store then denying the further request to acquire the lock for the second pathname.