-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Add a simple deadlock detector for require locks. #4095
base: master
Are you sure you want to change the base?
Conversation
I'm opening this PR to discuss the implementation and seek input. A few known issues:
|
I made a modification to mitigate known issue 2 above: it now will attempt to lock FIRST, only doing deadlock detection if that attempt fails. |
should safe fail when mx ( |
@kares Indeed...it would likely just skip this code. This general pattern may be applicable elsewhere, so this should move into its own utility class. |
0c53b64
to
2d6762e
Compare
Punting to 9.1.4.0. Too risky to stitch in at the last moment for 9.1.3.0. |
2d6762e
to
58cc903
Compare
Needs rebase and more thought. Bumping and rebasing. |
This detector works only with two threads, using the following heuristic: 1. If the lock is already acquired, obtain its owner thread. 2. Check if the owner thread is waiting on a lock. 3. If the lock the owner is waiting on is held by the current thread, raise an error. 4. If there's no owner and no deadlock, try to lock the thread for 500ms + rand(100)ms. 5. If the file has been locked, return success. 6. Otherwise, start over at 1. We may want a more advanced detector that can handle arbitrarily many threads, but it would be much heavier and require scanning all threads in the system, including those unrelated to the current program and those not actually trying to require files. See #3341.
58cc903
to
a6e70e3
Compare
De-targeting. This may be useful some day but there's work required and many open questions. |
This detector works only with two threads, using the following
heuristic:
thread, raise an error.
500ms + rand(100)ms.
We may want a more advanced detector that can handle arbitrarily
many threads, but it would be much heavier and require scanning
all threads in the system, including those unrelated to the
current program and those not actually trying to require files.
See #3341.