-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows #10822
Conversation
…rmittently on Windows
👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. But I think mainSync is not needed now. Thread 1 will always get to wait() before Thread 2 reaches the notify() call while loading D, so that should be enough to avoid the lost notification issue.
@coleenp This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 59 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Thanks Patricio, I don't need mainSync anymore because the first thread will wait. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your are doing an unconditional wait()
which in theory could be affected by a spurious wakeup. If you actually do:
while (!DisLoading) {
wait();
}
with a corresponding
DisLoading = true;
notify();
then I think you could dispense with the semaphore altogether.
…loader locked region, and guard against spuriouss wakeups.
I need to both handle 1. the spurious wakeup from wait(), and 2. the case where the second thread loads everything, and then the first thread then waits, after D's notification - the missed notification. |
That is what |
It won't test what I'm trying to test though, but maybe it's ok. I added the test for illustrative purposes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry Coleen some of the intermediate changes here confused me. The original use of mainSync
is slowing down thread1 (loading A) so that it can't proceed until thread 2 starts to load C and has the lock of L2 (which sets up the potential deadlock scenario). That could be added back in conjunction with the dIsLoaded
usage. In both cases thread 2 could always get to go first and load C and D before thread 1 has a chance to do anything.
@@ -36,19 +36,17 @@ | |||
|
|||
public class SuperWaitTest { | |||
|
|||
private static Semaphore mainSync = null; | |||
private static volatile boolean dIsLoading = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't need to be volatile as it is only accessed under the classloader lock.
My n-1 change makes thread 2 wait for loading C and D until thread1 is in the locked region for loading A (which was the deadlock scenario before the wait() is introduced). It doesn't really matter if thread 2 goes first with the dIsLoading change. Either way, the test will complete and not miss a notify. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay this seems fine from a logic perspective. There's one nit below that I missed before but up to you whether to change it.
Thanks.
@@ -36,19 +36,17 @@ | |||
|
|||
public class SuperWaitTest { | |||
|
|||
private static Semaphore mainSync = null; | |||
private static boolean dIsLoading = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: sorry just noticed the placement here. This is really an instance field of MyLoaderOne.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed it.
Thanks for the reviews Patricio and David. |
Going to push as commit a8450b3.
Your commit was automatically rebased without conflicts. |
I added another semaphore so the test will run in the order I want it to. Alternate suggestions or corrections welcome.
Running with GHA, and our tier1 in progress.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822
$ git checkout pull/10822
Update a local copy of the PR:
$ git checkout pull/10822
$ git pull https://git.openjdk.org/jdk pull/10822/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10822
View PR using the GUI difftool:
$ git pr show -t 10822
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10822.diff