fix: #101 guard atomic shutdown hook with locked flag#114
Open
bibonix wants to merge 1 commit into
Open
Conversation
Skip the unlock call when the lock was never acquired, so a JVM exit during the acquisition wait or after a thrown lock() or sleep() no longer releases another holder's lock through the empty default label.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the spurious unlock at JVM shutdown described in #101. When the shutdown hook is installed before the acquisition loop reports success, a JVM exit during the wait — or an exception thrown by
lock()orsleep()beforethis.locked.set(true)— used to callthis.lock.unlock(this.label)for a lock that was never held; with the default empty label that release could match another holder on the server.The fix in
src/main/java/co/stateful/Atomic.javaguards the hook body with an earlyif (!this.locked.get())return, so the hook short-circuits whenever the acquisition step did not flip the flag. Successfulcall()paths still unlock through the existingfinallyblock and remove the hook there, so behaviour for held locks is unchanged.Ran
mvn --batch-mode --errors clean install -Pqulice -DskipITs=trueagainst the change: build succeeded, every unit test undersrc/test/java/co/statefulpassed, and Qulice's quality gate completed without new findings.Closes #101