Skip to content

Only set locking thread once successful#9259

Merged
headius merged 2 commits intojruby:masterfrom
headius:deadlock_interrupted_lock
Feb 24, 2026
Merged

Only set locking thread once successful#9259
headius merged 2 commits intojruby:masterfrom
headius:deadlock_interrupted_lock

Conversation

@headius
Copy link
Member

@headius headius commented Feb 24, 2026

If the lockingThread is set before handling interrupts, and those interrupts cause the lock to be unlocked, the lock state will be broken for future fibers on the same thread and potentially for other threads. We move the set of lockingThread after we are sure we've successfully locked without interrupt and are about to return.

Fixes #9218

If the lock is acquired but we are immediately interrupted by
another thread, it will be unlocked while leaving the lockingThread
field set. This will cause all future locks by other fibers on that
thread to trigger a deadlock error, since the lock will appear to
have been acquired by a different fiber on that thread.

Patch by @yamam.

Fixes jruby#9218
In jruby#9218 a user discovered that thread interrupt during
an attempt to lock a mutex may render that mutex unusable from any
other fiber, even if it did not successfully lock. This spec tries
to trigger that state by having one thread loop while triggering a
raise interrupt on another thread that repeatedly locks a mutex
from within fibers.

This may not always fail when it is broken due to the timing issues
involved in triggering the interrupt after the lock was acquired
but before interrupts have been handled by the fiber, but 10x seems
sufficient to trigger the bug on JRuby.
@headius headius added this to the JRuby 10.0.4.0 milestone Feb 24, 2026
@headius headius merged commit 58905f5 into jruby:master Feb 24, 2026
79 checks passed
@headius headius deleted the deadlock_interrupted_lock branch February 24, 2026 05:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JavaFX AnimationTimer + Mutex.synchronize triggers “deadlock; lock already owned by another fiber belonging to the same thread” on JRuby 10.0.3.0

1 participant