On Wed, 13 Oct 2021 20:59:44 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` > is done waiting on it until after `trackAppResume()` is done, and since > `trackAppResume()` needs to grab the handlerLock, and you need to grab the > handerLock before the threadLock, you need to jump through some lock > grabbing/release hoops. That's correct. > However, you are in fact releasing the threadLock for a short time in > `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the > resumee to potential suspending after the wait has completed and before > `trackAppResume()` has been called? That's correct too. I wouldn't see an issue with it though. I think this is even a preexisting condition. The current thread can lose the race grabbing threadLock after it was notified to the debugger trying to suspend again (if there wasn't the deadlock of course) and consequently suspendCount can (again) be greater than 0 right after the wait. In that case we simply retry. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849
