Skip to content
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

Interrupting a thread during lock acquisition can cause deadlock #1

fridgebuzz opened this issue May 31, 2014 · 0 comments


Copy link

Because the locking methods call blocking methods that throw InterruptedException, the handling of these needs more care, so as not to leave the lock in a deadlocked or bugged state. Logically, this can happen during shutdown. Current symptom is that the DistributedReadWriteLockIT integration test fails if the tests of lockInterruptibly are run. The solution is first to define cancellation policies for each lock method (e.g. will it complete or try to return early? Is it interruptible only during method entry? What guarantees are we making about the state?) and then implement and document them. Cancellation anywhere other than on method entry can be difficult and expensive because it requires cleaning up after yourself. All lock methods have to at least leave the lock in a consistent state, otherwise thread interruption (e.g. Shutting down one server in a cluster) can cause deadlock across the whole cluster. Oops! That would be bad. Already working on a fix.

@fridgebuzz fridgebuzz self-assigned this May 31, 2014
@fridgebuzz fridgebuzz added the bug label May 31, 2014
@fridgebuzz fridgebuzz changed the title Interruptible tests in DistributedReadWriteLockIT causing other tests to fail Interrupting a thread during lock acquisition can cause deadlock Jun 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

No branches or pull requests

1 participant