Anticipatory Resource Modification via Private Copies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In computer systems, there is a delay between a process requesting permission to modify a resource and when it is allowed to begin modifying it, especially when upgrading from a share lock to an exclusive lock, due to the need for other processes to downconvert their locks, leading to inefficiencies in resource utilization.
Innovation Solution
The system allows a process to make anticipatory changes to a private copy of the resource before being granted an exclusive lock, by sending a 'proceed' message when only share lock holders are present and no pending exclusive requests exist, enabling modifications to start before the lock is officially granted, with changes becoming permanent once all locks are downconverted and the exclusive lock is granted.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a process waits for all share lock holders to downconvert before modifying a resource, then resource access consistency is maintained, but resource utilization efficiency deteriorates
Solution Approach 1:
The system applies preliminary action by allowing a process to make anticipatory changes to a private copy of the resource before being granted an exclusive lock. When the lock manager determines that only share lock holders are present and no pending exclusive requests exist, it sends a 'proceed' message to the requesting process, enabling modifications to start in advance. The changes become permanent once the exclusive lock is officially granted, thus improving resource utilization while maintaining consistency through the rollback mechanism if needed.
2Speed
If a process is granted an exclusive lock before other processes downconvert, then resource modification speed improves, but lock management complexity increases
Solution Approach 1:
The lock manager performs preliminary assessment by checking the state of all locks before granting exclusive access. It determines whether only share lock holders are present and whether no pending exclusive requests exist, then proactively sends a 'proceed' message to enable immediate modification. This controlled approach grants speed improvement while managing complexity through systematic state verification.
Solution Approach 2:
The system implements feedback mechanisms by continuously monitoring the lock state and using this information to make intelligent decisions about when to grant anticipatory access. The lock manager receives feedback about share lock holders and pending requests, and uses this feedback to determine whether conditions are appropriate for sending the 'proceed' message, thus balancing speed and complexity through informed control.
3Loss of time
If anticipatory changes are allowed before exclusive lock is granted, then processing delay is reduced, but system reliability risk increases
Solution Approach 1:
The system enables preliminary modifications by allowing processes to make anticipatory changes to private copies of resources before exclusive lock is granted. This reduces processing delay by eliminating the waiting period. The changes are made to private copies rather than the shared resource directly, and become permanent only after the exclusive lock is officially granted, thus managing reliability risk through controlled timing and isolation.
Solution Approach 2:
The system uses copying by creating private copies of the resource that can be modified anticipatorily without affecting the shared resource. The requesting process works on its private copy while waiting for the exclusive lock, and only commits the changes to the shared resource once the lock is granted. This copying mechanism isolates the reliability risk, as anticipatory changes to private copies cannot compromise the integrity of the shared resource.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method and system are provided for performing anticipatory changes to a resource governed by a locking mechanism. Entities (such as transactions in a database system) that want to modify a resource request permission to modify the resource. However, prior to receiving permission, they make anticipatory changes to a private version of the resource. The entities are prevented from making the anticipatory changes permanent until they receive permission to make the changes. Because they can make the changes, and proceed to other operations, before receiving permission, any delay in receiving permission has less adverse effect on their performance.