-
Notifications
You must be signed in to change notification settings - Fork 0
Add validation of lock ordering #116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this 8000 comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds validation of lock ordering to ensure that only a single element lock is held at once and to prevent taking the expiry lock while holding an element lock. Key changes include:
- Replacing direct lock/unlock calls with methods that return a release token and require passing that token for unlocking.
- Introducing a new LockOrderGuard class that tracks lock ownership and validates lock ordering.
- Updating multiple modules (TimeDelayedElement, LRUElementList, InnerArc, ExpiredElementList, Element, and Arc) to integrate the new lock validation mechanism.
Reviewed Changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
lib/src/main/java/eu/aylett/arc/internal/TimeDelayedElement.java | Updated lock usage to capture and use a release token |
lib/src/main/java/eu/aylett/arc/internal/LockOrderGuard.java | New guard class to enforce lock ordering |
lib/src/main/java/eu/aylett/arc/internal/LRUElementList.java | Modified locking to use the new release-based mechanism |
lib/src/main/java/eu/aylett/arc/internal/InnerArc.java | Added assertions to ensure no element lock is held during eviction lock operations |
lib/src/main/java/eu/aylett/arc/internal/ExpiredElementList.java | Updated lock handling with release tokens |
lib/src/main/java/eu/aylett/arc/internal/Element.java | Refactored lock and unlock to work with LockOrderGuard |
lib/src/main/java/eu/aylett/arc/Arc.java | Integrated LockOrderGuard and updated element locking usage |
} | ||
|
||
@EnsuresLockHeld("this.lock") | ||
public void lock() { | ||
@MayReleaseLocks | ||
public LockOrderGuard.Release lock() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a JavaDoc comment here to clarify that the lock method returns a release token which must be used in the corresponding unlock(LockOrderGuard.Release) method.
Copilot uses AI. Check for mistakes.
return evictionLock.tryLock(); | ||
} | ||
|
||
@EnsuresLockHeld("this.evictionLock") | ||
@ReleasesNoLocks | ||
public void takeEvictionLock() { | ||
lockOrderGuard.assertNoElementLockHeld(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a comment to explain why asserting that no element lock is held before acquiring the eviction lock is crucial for maintaining the lock order invariants.
Copilot uses AI. Check for mistakes.
|
This ensures we only take a single element lock at once, and also that we don't try to take the expiry lock while holding an element lock. Taking an element lock while holding the expiry lock is expected.
d726698
to
61214d4
Compare
|
This ensures we only take a single element lock at once, and also that we don't try to take the expiry lock while holding an element lock.
Taking an element lock while holding the expiry lock is expected.